Opened 5 years ago

Last modified 4 months ago

#10001 open bug

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

Change History (5)

comment:1 Changed 5 years ago by tj.vantoll

Status: newopen
Summary: Datepicker "Unix timestamp" is not Unix timestampDatepicker: "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.

comment:2 Changed 4 years ago by pgpp05

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...

comment:3 Changed 3 years ago by Sergiy Borodych

Any news?

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

comment:4 Changed 2 years ago by Phil Hilton

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.

Last edited 2 years ago by Phil Hilton (previous) (diff)

comment:5 Changed 4 months ago by jenka1980

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.

Note: See TracTickets for help on using tickets.