<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr" class="gmail_attr">On Tue, 11 Jun 2019 at 16:15, Guy Harris <<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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*?)<br></blockquote><div><br></div><div>Not presently, but Egypt did in 2014 and Morocco did from 2012 through late-2018.</div><div><br></div><div>On Tue, 11 Jun 2019 at 16:15, Guy Harris <<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">        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.<br><br>This is sufficiently vague (probably deliberately so) that:<br><br>        turning clocks forward from standard time in spring and summer could be called "Daylight Saving Time";<br><br>        turning clocks backward from standard time in autumn and winter could be called "Daylight Saving Time";<br><br>        adjusting clocks for Ramadan could be called "Daylight Saving Time";<br><br>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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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 <i>ever</i> necessarily been meaningful for any given purpose, apart from possibly the limited use of tm_isdst for disambiguation of repeated timestamps.</div></div><div dir="ltr"><br clear="all"><div><div dir="ltr" class="m_6227876695544229333gmail_signature" data-smartmail="gmail_signature">--<br>Tim Parenti</div></div></div></div>