On Wed, Feb 20, 2013 at 9:51 AM, Allen Wirfs-Brock <[email protected]>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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
