ISO/JSON date format timezone questions
On 7/13/07, doekman at gmail.com <doekman at gmail.com> wrote:
Hi, I was wondering about two things involving timezones.
The proposal "Date and time improvements" is defining the Date.toISO():String method.
It's unclear to me in what timezone the date should be serialized in: local timezone or UTC. Although it's semantically correct to allow both and let the implementors decide, but I think that would be "not a good thing".
I prefer is to be serialized in UTC (with the Z suffix).
I agree. I'll update the proposal.
The downside of this is, all json users will have to support time-zones.
As opposed to the current situation, when they have no idea what the time stamp means? ;-)
The advantage is, you can truncate two arbitrary json-date strings, and compare them, even if the dates are serialized in different timezones.
The other question is concerning the "JSON encoding and decoding" proposal. Is the Date serialization using the (fixed) formatting of www.json.org/json.js, or is it using the toISO method, mentioned above?
JSON has no syntax for time or date data, according to the grammar on json.org. The code you reference does format dates as strings, however, and it contains a comment which states that eventually dates will be formatted according to Date.prototype.toISOString(). This seems natural to me, as the ISO date format is unambiguous and compact.
So far the committee has been happy not to write any code for toJSONString, instead (informally) incorporating the code on json.org by reference. That may or may not change in the future.
On 7/16/07, Lars T Hansen <lth at acm.org> wrote:
On 7/13/07, doekman at gmail.com <doekman at gmail.com> wrote:
Hi, I was wondering about two things involving timezones.
The proposal "Date and time improvements" is defining the Date.toISO():String method.
It's unclear to me in what timezone the date should be serialized in: local timezone or UTC. Although it's semantically correct to allow both and let the implementors decide, but I think that would be "not a good thing".
I prefer is to be serialized in UTC (with the Z suffix).
I agree. I'll update the proposal.
Actually the proposal states (last sentence on the page) that the timezone field is always present and never Z. It's possible that is an external requirement; I'll have to look into it further.
Actually the proposal states (last sentence on the page) that the timezone field is always present and never Z. It's possible that is an external requirement; I'll have to look into it further.
You probably have a newer version than mine: developer.mozilla.org/es4/proposals/date_and_time.html#iso_date_strings
This proposal also states the T in date/time is mandatory, and the rest is optionally: timestamp ::= date? "T" time? tz?
a bit odd. I'm glad there's a new version.
doekman at gmail.com scripsit:
This proposal also states the T in date/time is mandatory, and the rest is optionally: timestamp ::= date? "T" time? tz?
a bit odd. I'm glad there's a new version.
In general the T is mandatory if a time follows: that differentiates 200707 (July 2007) from T200707 (20:07:07 on an unspecified date).
On 7/17/07, John Cowan <cowan at ccil.org> wrote:
doekman at gmail.com scripsit:
This proposal also states the T in date/time is mandatory, and the rest is optionally: timestamp ::= date? "T" time? tz?
a bit odd. I'm glad there's a new version.
In general the T is mandatory if a time follows: that differentiates 200707 (July 2007) from T200707 (20:07:07 on an unspecified date).
In ES4 the T is mandatory, period. This is a little odd and conflicts mildly with eg the W3C date note, which requires the T only if a time is present.
This artifact is at least in part a result of wanting to be able to distinguish ISO dates unambiguously from anything else that is passed to Date.parse for its delectation (you'd be surprised), without trying to specify more fully what Date.parse can accept. If we did try to specify Date.parse more fully it would be largely irrelevant -- all the browsers have extensive heuristics, and all existing web pages must continue to work. So in practice, implementations will grok 2007-07 even if they are not required to, but only 2007-07T is guaranteed to be parsed as an ISO date: without the T, you're at the mercy of the implementation's heuristics.
(Historically, the mandatory T is also an artifact of an attempt to get date literals into the language, but that proposal has been rejected.)
The situation with dates is overall less than satisfactory, but backwards compatibility binds us in significant ways and we feel support for ISO dates at least lets good developers write code that is unambiguous, a clear step forward from 3rd Edition.
An alternative to the mandatory T would be introducing a new parse method (parseISO?), but in practice Date.parse() will have to handle ISO dates regardless, so this is what we've come up with.
On 7/16/07, Lars T Hansen <lth at acm.org> wrote:
On 7/16/07, Lars T Hansen <lth at acm.org> wrote:
On 7/13/07, doekman at gmail.com <doekman at gmail.com> wrote:
Hi, I was wondering about two things involving timezones.
The proposal "Date and time improvements" is defining the Date.toISO():String method.
It's unclear to me in what timezone the date should be serialized in: local timezone or UTC. Although it's semantically correct to allow both and let the implementors decide, but I think that would be "not a good thing".
I prefer is to be serialized in UTC (with the Z suffix).
I agree. I'll update the proposal.
Actually the proposal states (last sentence on the page) that the timezone field is always present and never Z. It's possible that is an external requirement; I'll have to look into it further.
Resolved: toISOString() always produces a UTC timestamp with the "Z" suffix. Eventually JSON users should be able to count on this.
ISO timestamps can be recognized and picked apart by a simple ES4 regular expression, reproduced here for your collective amusement:
static const isoTimestamp : RegExp! =
/^
# Date, optional
(?: (?P<year> - [0-9]+ | [0-9]{4} [0-9]* )
(?: - (?P<month> [0-9]{2} )
(?: - (?P<day> [0-9]{2} ) )? )? )?
T
# Time, optional
(?: (?P<hour> [0-9]{2} )
(?: : (?P<minutes> [0-9]{2} )
(?: : (?P<seconds> [0-9]{2} )
(?: \. (?P<fraction> [0-9]+ ) )? )? )? )?
# Timezone, optional
(?: (?P<zulu> Z )
| (?P<offs>
(?P<tzdir> \+ | - )
(?P<tzhr> [0-9]{2} )
(?: : (?P<tzmin> [0-9]{2} ) )? ) )?
$/x;
I was wondering about two things involving timezones.
The proposal "Date and time improvements" is defining the Date.toISO():String method.
It's unclear to me in what timezone the date should be serialized in: local timezone or UTC. Although it's semantically correct to allow both and let the implementors decide, but I think that would be "not a good thing".
I prefer is to be serialized in UTC (with the Z suffix). The downside of this is, all json users will have to support time-zones. The advantage is, you can truncate two arbitrary json-date strings, and compare them, even if the dates are serialized in different timezones.
The other question is concerning the "JSON encoding and decoding" proposal. Is the Date serialization using the (fixed) formatting of www.json.org/json.js, or is it using the toISO method, mentioned above?