Operating with arbitrary timezones

Wed Aug 10 19:59:06 UTC 2016

@Jordan, thanks a lot! Switching to a personal account then.

@Tab other people in this thread have explained this throughly, but in
essence answering certain questions about dates require knowing
thetimezone offset.
For example knowing when "yesterday" was in an arbitrary timezone is not
just a matter of taking a date and removing 24 hours from it. This is
mostly a "presentation" issue, but not necessarily a "display" issue, which
is why I'm saying it's not just something that Ecma 402 covers.

Moment-js and Intl.DateTimeFormat do a good job at displaying dates, but in
order to do arithmetic on local dates we end up having to use them and
parse their return values.

It should be straightforward to implement a library with a TimeZone class,
same as what the ICU library has (http://icu-project.org/
apiref/icu4j/com/ibm/icu/util/TimeZone.html), based on the Unicode CLDR
data. But this does look like something EcmaScript should provide. The only
reason I haven't done it and published it is because we want to avoid
having to ship all that historical CLDR data to the browser.

On Tue, Aug 9, 2016 at 3:47 PM, Claude Pache <claude.pache at gmail.com> wrote:

>
> 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 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?
>
>
>
> Well, if you want to be pedantic...
>
> You should disregard the *non-normative* introduction text found in
> 20.3.1.1, 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 20.3.1.2:
>
> 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
>
>
> —Claude
>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160810/17173f88/attachment.html>