Override LocalTZA

[Norbert Lindenberg]

The internationalization ad-hoc of TC 39 has already decided that edition 2 of the ECMAScript Internationalization API will support IANA time zone names in DateTimeFormat. Implementations will need to include best available information on all time zones or use equivalent operating system APIs.

I agree with Rich and Addison that adding a time zone to Date instances would only create confusion. I think the best way to add general support for time zones that's not tied to formatting would be methods that convert between incremental time (a Date instance) and field-based time. Under the covers, the Internationalization API spec already includes one direction as an abstract operation:
http://www.ecma-international.org/ecma-402/1.0/index.html#ToLocalTime
Note that this operation also takes a calendar - this hasn't come up on this thread yet, but is required because day/month/year values are always relative to a calendar.

Jon, Andrew: would a method similar to that operation address your needs?

Norbert


On Feb 20, 2013, at 12:52 , Phillips, Addison wrote:

> I agree that the tzinfo database and its identifiers should form the basis for ES time zone support. There are some issues with providing support, such as that it means that implementers will need to update several times a year (as time zone rules change).
>  
> Setting TimeZone on a Date object might not be the best design, even though that’s sort of the design of Date today. Date values internally are actually timestamps, “incremental time” [1] values---the number of millis since the epoch date in UTC. Making the time zone a property of the date would be confusing, since two incremental times are inherently comparable without reference to LTO (local time offset) or time zone rules.
>  
> The problem is that many of the methods of Date expose “field values” within the date—what is the day number or what is the hour number? Where TimeZones need to be used is when transforming dates to/from display. This should apply to the new Intl DateFormat stuff. Maybe adding methods that take a time zone or adding a time zone class might be better? There is the problem that Date today has separate methods that return the local value and the “GMT” value.
>  
> Addison
>  
> Addison Phillips
> Globalization Architect (Lab126)
> Chair (W3C I18N WG)
>  
> Internationalization is not a feature.
> It is an architecture.
>  
> [1] http://www.w3.org/TR/timezone/#incrementaltime
>  
> From: Jonathan Adams [mailto:pointlessjon at me.com] 
> Sent: Wednesday, February 20, 2013 8:03 AM
> To: Andrew Paprocki
> Cc: es-discuss
> Subject: Re: Override LocalTZA
>  
> Excellent points and ideas here. 
>  
> I do think it would be extremely valuable to enable the ability to override    any Date instance and don't think this is harmful.
>  
> Not sure how reasonable/unreasonable requiring tzdb for vendors but seems worth it. Dates are important. Exposing something like 
>  
> Date.setLocalTimezone('America/Los_Angeles') 
> Date.getLocalTimezone()
>  
> and leaving existing Date APIs untouched as well as preventing the guaranteed problems of the natural inclination to pass static offsets seems perfect.
> 
> -Jon-
> 
> On Feb 20, 2013, at 7:03, Andrew Paprocki <andrew at ishiboo.com> wrote:
> 
> On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> What would be the best way to expose the localTZA for you purposes?
>  
> Exposing localTZA at all would only lead to problems, IMO.
>  
> class CST extends Date {
>       get localTZA() {return -6*60*60*1000}
> }
>  
> Timezones can not be referred to as static offsets. The only error-free way to deal with timezones is to store the string (e.g. "Asia/Tokyo") and use tzdb when performing conversion into another timezone (in this case, most likely into UTC). UTC offset is a linear function that needs the full datetime as input. Any other representation of it immediately introduces bugs.
>  
> program.  What is the localTZA of those preexisting date instances.  Was it fixed when they were created or is the default localTZA potentially dynamically updated.  What would an application want to happen?
>  
> Precisely why you need to either store a fixed offset (fixed point in time -- and realize that is what you're doing) or you need to store the full timezone string (in the case of recurring events). Recurring events could not be hacked up with a localTZA modification. If a recurring meeting occurs at 4pm every day in NY, "America/New_York" will needed to be used to compute that in other timezones to avoid errors. Also, you don't even need to get on a plane and fly. For example, if you live in the Middle East, you are in the middle of a work day when the US EST/EDT shifts happen. If you're referring to NY datetimes and using a fixed or precomputed offset instead of treating the conversion as a linear function, there will be errors.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss