#10001 open bug ()

Opened April 28, 2014 03:08PM UTC

Last modified September 04, 2018 08:42AM UTC

Datepicker: "Unix timestamp" is not Unix timestamp

Reported by: jameshfisher Owned by:
Priority: minor Milestone: none
Component: ui.datepicker Version: 1.10.4
Keywords: Cc:
Blocked by: Blocking:
Description

From Wikipedia (http://en.wikipedia.org/wiki/Unix_time):

Unix time (aka POSIX time or Epoch time), is a system for describing instants in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970,[note 1] not counting leap seconds.

From the jQuery UI documentation (http://api.jqueryui.com/datepicker/#utility-formatDate):

@ - Unix timestamp (ms since 01/01/1970)

These are obviously inconsistent: Wikipedia claims the number to represent seconds; jQuery UI claims it represents milliseconds. It seems obvious to me that Wikipedia (and the many other sources that are consistent with it) should take precedence here, and so the jQuery UI documentation is wrong.

I therefore recommend:

  • rewording the documentation for '@' to something like "@ - JavaScript timestamp (ms since 01/01/1970)"
  • introducing another format element, e.g. "UNIX", with the documentation "UNIX - UNIX timestamp (seconds since 01/01/1970)", and with the obvious semantics
Attachments (0)
Change History (5)

Changed April 28, 2014 06:07PM UTC by tj.vantoll comment:1

status: new → open
summary: Datepicker "Unix timestamp" is not Unix timestamp → Datepicker: "Unix timestamp" is not Unix timestamp

Interesting. I verified that when you ask for a UNIX timestamp in jQuery UI you do get milliseconds. Honestly I'm wondering why we support UNIX timestamps because—unless I'm missing something—they're easy to derive. I'll check if Globalize has any concept of this for the rewrite.

Changed February 10, 2015 03:26PM UTC by pgpp05 comment:2

Unix timestamps are often used with altField, since many systems await unix timestamps in the form submitted data.

It's very easy to add the corresponding "s" format

case "s":

output += Math.floor(date.getTime()/1000);

break;

But would probably break descendant compatibility if users used 's' as an unquoted literal...

Changed April 15, 2016 01:54PM UTC by bor comment:3

Any news?

I have got the same misunderstanding and have spent some time to understand what's going on :(

Changed October 26, 2016 02:39AM UTC by PhilHilton comment:4

_comment0: I gotta say, this caused me about an hour of lost time trying to figure out that what the documentation calls a unix timestmp isn't a a unix timestmp and that I wasn't really passing a unix timestamp off to other functions. \ \ If we don't want to fix the tool or add support for a real unix timestamp that's fine, but the documentation should at least be updated so it's not trying to incorrectly redefine what a unix timestamp is. → 1477449680421258

I gotta say, this caused me about an hour of lost time trying to figure out that what the documentation calls a unix timestmp isn't really a unix timestmp and that I wasn't really passing a unix timestamp off to other functions.

If we don't want to fix the tool or add support for a real unix timestamp that's fine, but the documentation should at least be updated so it's not trying to incorrectly redefine what a unix timestamp is.

Changed September 04, 2018 08:42AM UTC by jenka1980 comment:5

Same thing for me wasted time because of wrong documentation.

So the first thing to do is at least fix the documentation so other developers won't struggle with this problem.