On Fri, Aug 5, 2016 at 5:30 PM, Tab Atkins Jr. <[email protected]> wrote:
> On Fri, Aug 5, 2016 at 1:59 PM, Kris Siegel <[email protected]> wrote: > >> Once you endow them with a timezone offset they cease to represent > points > >> in time, but rather more points in space, which adds complexity and > >> liability to any code handling Date objects > > > > > > I would disagree. Time isn't useful without a point in space (space and > time > > should be looked at as one thing, not two) and since the Date object > tracks > > it internally as UTC it has a default space. > > This is incorrect. It tracks a UTC timestamp; the current time as I > write this is 1470432591121 milliseconds since the epoch, and that's > true regardless of where you are on the planet. > Yep. > > Timezones are a *display* concept - they affect how you parse > human-readable strings into timestamps, and how you display a > timestamp as a human-readable string. This is similar to the > distinction between Unicode values and strings encoded in UTF8. > Time zones are not *just* for display. They're are also necessary for doing date arithmetic on a local timeline (assuming the most common and, IMO, useful sort of date arithmetic). For example: if I ask you, "What date and time is it exactly one day after March 12, 2016 at 3pm in the America/New_York time zone," how do you answer? If you take "one day" to mean 24 hours, then the answer is March 13, 2016 at 4pm in America/New_York (because of daylight saving time), but most libraries that implement date arithmetic will give you March 13, 2016 at 3pm, etc., etc. -- because that's what users tend to expect out of date arithmetic (as opposed to time arithmetic). - Jon
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
