[tz] Java & Rearguard

[Tim Parenti]

On Tue, 11 Jun 2019 at 16:15, Guy Harris <guy at alum.mit.edu> wrote:

> Some parts of the world don't do seasonal adjustment, although they may do
> adjustments for Ramadan.  (Are there any countries that do both seasonal
> adjustment *and* Ramadan adjustment *in the same year*?)
>

Not presently, but Egypt did in 2014 and Morocco did from 2012 through
late-2018.

On Tue, 11 Jun 2019 at 16:15, Guy Harris <guy at alum.mit.edu> wrote:

>         The value of tm_isdst is positive if Daylight Saving Time is in
> effect, zero if Daylight Saving Time is not in effect, and negative if the
> information is not available.
>
> This is sufficiently vague (probably deliberately so) that:
>
>         turning clocks forward from standard time in spring and summer
> could be called "Daylight Saving Time";
>
>         turning clocks backward from standard time in autumn and winter
> could be called "Daylight Saving Time";
>
>         adjusting clocks for Ramadan could be called "Daylight Saving
> Time";
>
> etc., as they all are "temporary change[s] in the algorithm for
> determining local time".  That does raise the question of whether
> "permanent Daylight Saving Time" would count.


And this, really, is the crux of the issue.  DST is fundamentally just like
any other shift in offset.  The only distinction is cultural: DST shifts,
in whatever form, are generally seasonal, whereas other changes to offset
may not be.  But ultimately, you're still doing nothing more than just
changing how local time is described in some way.

If we were redesigning all these systems from scratch with a better
understanding of the variability in worldwide timekeeping practices, the
notion of "is this or is this not DST?" being answerable should seem absurd
because, in practice, it is.  And it's not relevant in the slightest to the
task of computing civil time.

Likewise for "SAVE" values, which are never necessary to compute civil time
and, as I understand it, are intentionally omitted from TZif files because
they are unnecessary.  Rather, "SAVE" is simply a shorthand used in the
source data files to more efficiently generate the individual offsets and
transitions used in the TZif output.  If one uses tm_isdst to apply a
"SAVE" value to some notion of "standard time", one is getting no more
useful information than could have been gotten by just using the TZif
directly.  That my locale observes UTC−5 at other times of the year has no
bearing on calculating the current time here; the only thing that matters
(both in a practical and legal sense) is that we're currently on UTC−4.

None of this absolves us from coming to workable solutions to the issues
raised, of course.  But it does mean that users should disabuse themselves
of ideas that these fields have *ever* necessarily been meaningful for any
given purpose, apart from possibly the limited use of tm_isdst for
disambiguation of repeated timestamps.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190611/ea84e4ed/attachment.html>