Opened 9 years ago
Last modified 4 years 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 9 years ago by
Status: | new → open |
---|---|
Summary: | Datepicker "Unix timestamp" is not Unix timestamp → Datepicker: "Unix timestamp" is not Unix timestamp |
comment:2 Changed 8 years ago by
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 7 years ago by
Any news?
I have got the same misunderstanding and have spent some time to understand what's going on :(
comment:4 Changed 6 years ago by
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.
comment:5 Changed 4 years ago by
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.
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.