Operating with arbitrary timezones

[peter miller]

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 20.3.1.1 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?