Operating with arbitrary timezones

Claude Pache claude.pache at gmail.com
Tue Aug 9 22:47:07 UTC 2016

> Le 8 août 2016 à 20:51, peter miller <fuchsia.groan at virgin.net> a écrit :
> On Fri, 05 Aug 2016 22:30:28 +0100, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
> Much of what follows is wanton pedantry, for which I apologise. ;)
>>> 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.
> I suspect you've dropped 36s from that count or used 1st January 1970 0h 0m 36s as your epoch.  I might be wrong. But if you have, it's because Universal Time is a "rotational timescale": it measures the angle of a fictitious point in the sky (U) relative to the prime meridian and not a linear count of seconds. The IERS (International Earth Rotation and Reference Systems Service) measures the angle of U and issue "Universal Time" (UT1). With UTC being kept within one second of UT1 via leap seconds (next one at the end of year).
> The value an observer measures for U, called UT0, really does depend on their exact position on the surface of the earth. That has to be adjusted for. That said, UT1/UTC are notionally the same for us all. And I know that's what you were saying. Like I said, I'm showing off my very hard won knowledge.
> And I might as well point out UT is defined on the earth's surface. It's affected by gravity.
>> 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.
> Sure, calendar dates (year, month and day) are a human-friendly way of displaying the number rotations of U over a meridian.
> But I think timezones represent a change in meridian. I believe in the olden days people would set their watches to a local meridian. (I'm reading Verne's _Mysterious_Island_ at the moment
> and it contains a reference to a chronometer set to the Washington meridian.)  And while the "timezones" we use in modern civil life are a political construct, I suspect a timezone is still saying display the transits of U over such-and-such a meridian; it's a shift in longitude, not directly a shift in time.
> As a final unrelated comment, I wonder whether should explicitly define javascript time values to be:
> `d * 86400000 + ms`
> Where `d` is the number of whole UTC days elapsed since midnight 1 January 1970 and `ms` is the number of milliseconds elapsed since the start of current UTC day, with the value of `ms` being implementation defined close to a leap second - and possibly diverging from thousandths of an SI second.
> I think that's what the existing standard is trying to say but the current phrasing feels wrong, and the above makes clear that timevalues are a construct used to represent UTC not a count of millseconds since epoch (which javascript dates can never be because they exclude the 36---soon to be 37---leap seconds).
> Peter
> PS: Can we not add underscores to numbers? Would allowing 86_400_000 break the web?

Well, if you want to be pedantic...

You should disregard the non-normative introduction text found in, which might be slightly imprecise:

Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day.

and pay more attention to the normative definitions given in

A given time value t belongs to day number

Day(t) = floor(t / msPerDay)

where the number of milliseconds per day is

msPerDay = 86400000

The remainder is called the time within the day:

TimeWithinDay(t) = t modulo msPerDay


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160810/157c7ed9/attachment.html>

More information about the es-discuss mailing list