[MAL, on DST for out-of-platform-mktime()-range years]
> My point was to not fiddle with the date at all: raise an
> exception and that's it.
If someone wants to print some datetime object from the year 1537 as =
if a
local time, raising an exception just because the local DST rules in =
effect
at that time are unknown seems extremely unfriendly. For goodness sa=
ke,
we're already "lying" to them about the calendar system in effect at =
that
time, and an hour more or less due to DST uncertainty is trivial. It=
's an
idealized calendar, and an idealized time.
We should supply a way for the user to find out whether or not a DST
correction was applied, though. ECMAScript does that via a
DaylightSavingTA(t)
function mapping UTC time to the number of milliseconds (all their ti=
mes are
in milliseconds) to be added to t to adjust for local DST. A distinc=
t
LocalTZA constant gives the number of msecs to add to UTC to adjust f=
or
local timezone.
Conversion from UTC to local time is defined by
LocalTime(t) =3D t + LocalTZA + DaylightSavingTA(t)
Conversion from local time to UTC is defined by
UTC(t) =3D t =96 LocalTZA =96 DaylightSavingTA(t =96 LocalTZA=
)
Note that UTC(LocalTime(t)) is not necessarily always equal to t.
That last line gives me an especially warm feeling <wink>.
there's-idealized-and-then-there's-idealized-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4