W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: [Alarm API] Time zone handling

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 9 May 2013 15:23:33 -0700
Message-ID: <CA+c2ei9k4eLPvUdNZfxea=fuu+bvRdr5-B_+5Wns6dFAeHN=Bw@mail.gmail.com>
To: public-sysapps <public-sysapps@w3.org>
Cc: Marcos Caceres <w3c@marcosc.com>, Norbert Lindenberg <w3@norbertlindenberg.com>, public-script-coord <public-script-coord@w3.org>
On Wed, May 8, 2013 at 6:15 PM, Norbert Lindenberg
<w3@norbertlindenberg.com> wrote:
> The time zone behavior in the spec seems to be based on a misunderstanding of how JavaScript handles time zones. In particular, there's a reference to "the timezone information of that [ECMASCRIPT] Date object".
> ECMAScript Date objects don't have time zone information. After construction, all a Date object has is a time value, the number of "milliseconds since 01 January, 1970 UTC" [1]. Time zone information is used in the constructor to calculate the new object's time value if the "year, month [, date [, hours [, minutes [, seconds [, ms ] ] ] ] ]" form of the constructor is used [2] and [3], or if a string is provided to the constructor for parsing [4] and [5]. No time zone information is used if a single non-String value is provided to the constructor [4]. Date objects represent incremental time [6].

Yeah, the vocabulary here is not entirely right. Like you say, Date
objects don't really contain timezone information, even though it can
seem like it due to having functions like getTimezoneOffset.

We should probably say that it uses the local timezone.

It would be nice to be forwards compatible with if ES adds support for
"real" timezone-aware Date objects, but I think it's hard to do that
without doing a lot of risky guessing about what such an API would
look like.

> In an API that's designed around a Date instance, time zone directives "respectTimezone" or "ignoreTimezone" are therefore meaningless. If the API is intended to interpret time zones (I don't know whether it is), it needs a different data type to represent field based time with time zone information [7].

This isn't however accurate. The API does actually meaningfully work
right now, it's just not described well as discussed above. The
easiest way to describe how it works is through examples. There are a
couple here:


/ Jonas
Received on Thursday, 9 May 2013 22:24:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC