Override LocalTZA

[Jonathan Adams]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130220/2bf058a0/attachment.html>