Operating with arbitrary timezones
zeppieri at gmail.com
Fri Aug 5 21:51:24 UTC 2016
On Fri, Aug 5, 2016 at 5:30 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Fri, Aug 5, 2016 at 1:59 PM, Kris Siegel <krissiegel at gmail.com> wrote:
> >> Once you endow them with a timezone offset they cease to represent
> >> 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
> > should be looked at as one thing, not two) and since the Date object
> > 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss