Internationalization: Support for IANA time zones

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Sat Mar 2 10:34:25 PST 2013


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]].

> 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 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.

Norbert


More information about the es-discuss mailing list