Override LocalTZA

[Andrew Paprocki]

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/53a02fd8/attachment.html>