ISO/JSON date format timezone questions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

ISO/JSON date format timezone questions

doekman
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). 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?
--
|\
| \
|_/oeke
[hidden email]
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ISO/JSON date format timezone questions

Lars T Hansen-2
On 7/13/07, [hidden email] <[hidden email]> 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.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ISO/JSON date format timezone questions

Lars T Hansen-2
On 7/16/07, Lars T Hansen <[hidden email]> wrote:

> On 7/13/07, [hidden email] <[hidden email]> 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.

--lars

> > 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.
>
> --lars
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ISO/JSON date format timezone questions

doekman
> 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:
http://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.
--
|\
| \
|_/oeke
[hidden email]
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ISO/JSON date format timezone questions

John Cowan
[hidden email] 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).

--
John Cowan              [hidden email]          http://www.ccil.org/~cowan
Any day you get all five woodpeckers is a good day.  --Elliotte Rusty Harold
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ISO/JSON date format timezone questions

Lars T Hansen-2
On 7/17/07, John Cowan <[hidden email]> wrote:

> [hidden email] 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.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ISO/JSON date format timezone questions

Lars T Hansen-2
In reply to this post by Lars T Hansen-2
On 7/16/07, Lars T Hansen <[hidden email]> wrote:

> On 7/16/07, Lars T Hansen <[hidden email]> wrote:
> > On 7/13/07, [hidden email] <[hidden email]> 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;

--lars

>
> --lars
>
> > > 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.
> >
> > --lars
> >
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss