Recapping items 5-8 of Bug 2701:
20.3.2.1 / step 5.a:
20.3.2.2 / step 10.a:
20.3.2.3 / step 14.a:
20.3.2.3 / step 15.a:
These say:
"... the time value (UTC) identifying the current time."
[And there are other uses of the term "UTC".]
--------
I said:
Saying "(UTC)" suggests that a time value is bound to a particular time zone, which it isn't.
--------
Allen Wirfs-Brock replied:
Saying (UTC) means the exact opposite: that the time value is a universal time
rather than a local time associated with a particular time zone. See the
definition of time value in 20.3.1.1.
Removing the "(UTC)" would make these phrases ambiguous WRT whether the
resulting timevalue should be a UTC value or a locally adjusted value.
These particular phrases have been in the ES spec. since the introduction of
Date object.
> Saying (UTC) means the exact opposite: that the time value is a universal
> time rather than a local time associated with a particular time zone.
That appears to be a somewhat wishful interpretation of UTC.
For most people's purposes, UTC is equivalent to GMT, which is more obviously bound to a time zone.
Also, as 20.3.1.1 makes clear:
In time values leap seconds are ignored.
It is assumed that there are exactly 86,400,000 milliseconds per day.
These statements are not true of UTC.
> See the definition of time value in 20.3.1.1.
Yes, in fact, to avoid these concerns, it would be better for the spec to say something like:
"... the time value (see 20.3.1.1) identifying the current time."
> Removing the "(UTC)" would make these phrases ambiguous WRT whether the
> resulting timevalue should be a UTC value or a locally adjusted value.
Given how 20.3.1.1 defines 'time value', I don't think that ambiguity exists. But if you think it does, it would perhaps be better to clarify that in one spot, rather than multiple spots. E.g., maybe add a paragraph to 20.3.1.1 about the meaning of the phrase "a time value identifying the current time". (Perhaps introduce a shorter term like "the current time value".)
There is also the introductory paragraph of Section 20.3.2 (The Date Constructor):
"When Date is called as a function rather than as a constructor, it returns a String representing the current time (UTC)."
The precision "(UTC)", at least when interpreted non-convolutedly, is contradicted by every implementation I've tried, for all of them give me a local time, e.g.:
"Thu May 15 2014 09:15:16 GMT+0200 (CEST)"
In order to avoid such a confusion, and similar ones, one should be precise on the vocabulary used.
* On the one hand, the notion of local time, time zone or universal time, and the abbreviation "UTC", are relevant when a time is expressed as an hour within a given day, e.g: "9.30am".
* On the other hand, a number of milliseconds (or days, or whatever) is just expressing a difference between two instants, and is independent to the notion of timezone or UTC. The "millisecond" is a duration completely defined by the International System of Units.
In fact, the spec is itself confused about the term "time value":
* In Section 20.3.1.1, the technical term "time value" seems to be defined as the number of milliseconds since the Epoch, plus a correction regarding leap seconds. Note that such a number isn't itself in UTC for any correct meaning of "UTC", even if some parts of its definition refer more or less implicitly to Universal Coordinated Time, such as the notion of leap second, or the usual definition of the Epoch.
* Section 20.3.1.6 Week Day (as a random example) gives a formula that computes the "weekday for a particular time value /t/". But the "time value /t/" used in that formula corresponds precisely to the number of milliseconds since 1st Jan 1970 midnight in a given timezone, in contradiction of the definition of "time value" given in Section 20.3.1.1.
In order to add clarity, one should use the technical term "time value" only exactly as defined in Section 20.3.1.1, rather than adding a spurious (UTC) precision in some cases. For instance, the introductory text of Section 20.3.1.6 could say: "The operator WeekDay calculates a week day from a given number of milliseconds since 1st Jan 1970 midnight in a given timezone ."