Operating with arbitrary timezones

[Jon Zeppieri]

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