Internationalization: Support for IANA time zones

Jonathan Adams pointlessjon at me.com
Sat Mar 2 11:27:10 PST 2013


On Mar 2, 2013, at 10:34 AM, Norbert Lindenberg <ecmascript at lindenbergsoftware.com> wrote:

> 
> On Mar 2, 2013, at 7:27 , Dean Landolt wrote:
> 
>> I agree it doesn't make sense to solve this problem in the context of formatting, but there wouldn't be an issue if we had a way to set the zone of a Date. In another thread it was claimed that "A Date is intended to represent a specific instance in time, irrespective of time zone". But this isn't true at all -- a Date already carries around a timezone tag internally.
> 
> What makes you believe that? According to the specification, the only data a Date instance has is the [[PrimitiveValue]] internal property, which is a time value, the number of milliseconds since 01 January, 1970 UTC:
> http://ecma-international.org/ecma-262/5.1/#sec-15.9.6
> http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1
> 
> The Date constructor and the functions creating Date instances may accept values expressed in the local time zone, but are all specified to calculate a time value in UTC, which then gets stored in the [[PrimitiveValue]].

To speak to Dean's implications, many of the Date methods operate on the [[PrimitiveValue]] adjusted for an environmental local offset. Unless specifying obvious UTC versions (e.g. Date.getDay() vs Date.getUTCDay()

So, it'd not that the local tz is carried around so much that all these methods rely on the environments. No?

> 
>> And if you believe there's no use case for changing a date's timezone, try partitioning a set of Dates by day (or week, month, year, etc.) using a day boundary in a timezone other the current locale's or Zulu. I've come up against this use case more than once, and The solution sucks. It involves shipping some subset of the tz db to the client, which is ridiculous -- especially because there's an easy fix...
> 
> That's a good use case, and you're right, it's currently not supported.
> 
>> A zone tag already exists, if implicitly, on Dates. What's the harm in making it explicit -- exposing it as a unique symbol? It could be made writable, and a registry of IANA timezones could be exposed as symbols.
> 
> According to the spec, there is no zone tag. Adding it would make simple operations like comparing the time values of two Date instances a lot more complicated, so I doubt we'd want to do that.

I don't follow how this would make anything more/less complicated if comparison operated on the [[PrimitaveValue]]. Especially if everything just defaults to the way it works now (grab environment's local offset). However, I get not wanting to muck up existing API..

> 
> I think a better solution would be API that either lets you easily generate a series of Date instances representing midnight (of every day, of every Monday, of every first day of the month, ...) in a specified time zone and calendar, or that lets you convert a Date to field-based time information in a specified time zone and calendar so that you can apply your own criteria.

Agree. 
> 
> Norbert
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


Jon Adams
Sent from my Refrigerator


More information about the es-discuss mailing list