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:pointless...@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 <and...@ishiboo.com> wrote:
> 
> On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock <al...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to