Normative: Handle "start of day" separately from "midnight" #2918
Conversation
|
I had to refactor ParseISODateTime, InterpretISODateTimeOffset, and InterpretTemporalDateTimeFields to use Time Records instead of individual integer time components. I'll split this out later into an editorial PR so that at least should simplify things a bit. |
|
Draft until presented at TC39. Tests are in tc39/test262#4158 |
|
lgtm as well. nice catch for ZonedDateTime.p.round |
ptomato
force-pushed
the
2910-startofday-in-canada-1919
branch
from
7fbb958
to
32e7b56
Compare
|
Missed a fix in the |
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
6fad4bd
to
4047d55
Compare
|
Would |
|
@SpikyC, since the lost hour you're referencing is between 2:30:00 and 3:30:00, the 00:00:00 wallclock time still exists and thus there's no issue. Reference: https://www.timeanddate.com/time/change/canada/montreal?year=1919 |
|
@arshaw |
|
If you have the version of the TZDB with the merges, in which America/Montreal is an alias for America/Toronto, then you will get this behaviour for America/Montreal as well. It is recommended, although not required, that JS implementations use the version of the TZDB without the merges: https://tc39.es/proposal-temporal/#sec-use-of-iana-time-zone-database |
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
4047d55
to
493ce51
Compare
This statement isn't quite accurate. What's discouraged (and disallowed once ECMA 402 PR #877 is merged soon) is merges between countries. Merges inside countries (like America/Montreal being merged into America/Toronto) are recommended to be supported. See that PR for more details about expected behavior. |
|
My mistake, thanks for clearing up the record! |
|
Achieved consensus at TC39 plenary 2024-07-30. |
ptomato
force-pushed
the
calendar-time-zone-removals
branch
2 times, most recently
from
74ec1c7
to
ffa4bd6
Compare
ptomato
force-pushed
the
calendar-time-zone-removals
branch
5 times, most recently
from
2b549d0
to
2fa1b21
Compare
ptomato
force-pushed
the
calendar-time-zone-removals
branch
from
ef56146
to
aa339b8
Compare
Fixes calculations of start of day in ZonedDateTime.prototype.hoursInDay, ZonedDateTime.prototype.startOfDay(), and ZonedDateTime.prototype.round() with smallestUnit: "day". Updates the following operations to explicitly mean "start of day" and not "midnight": - PlainDate.prototype.toZonedDateTime(timeZoneString) - PlainDate.prototype.toZonedDateTime(options) with omitted or undefined plainTime option - ZonedDateTime.prototype.withPlainTime() with no argument or undefined - Parsing 'YYYY-MM-DD[Zone]' anywhere a ZonedDateTime string is expected This is in order to handle one corner case from the TZDB where clocks were set one hour ahead in America/Toronto at 23:30 on March 30, 1919, meaning that the DST skipped hour encompassed midnight but did not start or end at midnight. (This was probably just in the city of Toronto and maybe some other towns, because time was still locally administered at that time.) Closes: #2910
ptomato
force-pushed
the
2910-startofday-in-canada-1919
branch
from
32e7b56
to
d9aff67
Compare
Fixes calculations of start of day in
ZonedDateTime.prototype.hoursInDay,ZonedDateTime.prototype.startOfDay(), andZonedDateTime.prototype.round()with smallestUnit: "day".Updates the following operations to explicitly mean "start of day" and not
"midnight":
PlainDate.prototype.toZonedDateTime(timeZoneString)PlainDate.prototype.toZonedDateTime(options)with omitted or undefinedplainTimeoptionZonedDateTime.prototype.withPlainTime()with no argument or undefinedYYYY-MM-DD[Zone]anywhere a ZonedDateTime string is expectedThis is in order to handle one corner case from the TZDB where clocks were set one hour ahead in America/Toronto at 23:30 on March 30, 1919, meaning that the DST skipped hour encompassed midnight but did not start or end at midnight. (This was probably just in the city of Toronto and maybe some other towns, because time was still locally administered at that time.)
Closes: #2910