Operating with arbitrary timezones

[Tab Atkins Jr.]

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.

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.

JS Date objects input/output using the user's local timezone. Luckily,
since Yahoo Mail apparently knows the user's preferred timezone (from
their settings), they can adjust things as appropriate themselves. The
important concept, tho, is that this adjustment is in *how you
parse/display datetimes*, not how you *store* them - storing is done
without any timezone information whatsoever.  It's not *trivial* to do
so (thus the success of libraries like moment.js), but it's at least
easier when you realize that Date objects represent exact points in
time, and timezone (and related things like "start of day") are
display-related only.

~TJ