[tz] tm_isdst: to be or not to be? [WAS: Did Greenland abolish daylight saving from 2024 on?]

[Fred Gleason]

On Nov 16, 2023, at 9:29 PM, Paul Eggert via tz <tz at iana.org> wrote:

> Not sure what is meant by "in effect". POSIX says "The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available." <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html>
> 
> So the intent of POSIX is that tm_isdst>0 means daylight saving time. The DST offset from UT need not be greater than the standard-time offset. POSIX (and TZDB) even allow the two offsets to be equal, though there's not much use for that.

In light of the seemingly significant confusion and divergences of understanding around exactly what “Daylight Saving Time” means in various jurisdictions (e.g. Ireland vs. North America vs. ??), perhaps it's time to consider just setting tm_isdat=-1 in all zones that do not return a fixed offset for the entire year? While this would effectively mean the retirement that field, how much modern software actually makes use of it? 

There is precedent for something like this: the deprecation of the "struct timezone *tz" argument to gettimeofday() and settimeofday(). The man page for those functions on my Linux system (CentOS 7, man-pages-3.53.-5) has this to say about that field in the NOTES section:

*** snip snip ***
On old systems, the field tz_dsttime contains a symbolic constant (val‐
ues are given below) that indicates in which part of the year  Daylight
Saving  Time is in force.  (Note: this value is constant throughout the
year: it does not indicate that DST is in force,  it  just  selects  an
algorithm.)   The  daylight  saving time algorithms defined are as fol‐
lows:

[… list of historical timezone IDs omitted …]

Of course it turned out that the period in which Daylight  Saving  Time
is  in  force  cannot  be given by a simple algorithm, one per country;
indeed, this period is determined by unpredictable political decisions.
So this method of representing timezones has been abandoned.
*** snip snip ***

It strikes me that we’ve arrived at a similar place WRT the “is_dst” field: namely, that it is too simplistic a mechanism for describing actual ground truth in 2023. POSIX provides a way to tell applications unambiguously that “we don’t know”. Perhaps we should take advantage of that?

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|    Never take two chronometers to sea. Always take one or three,    |
|    otherwise you'll never be sure what time it is.                  |
|                                                                     |
|                                                      -- Anonymous   |
|---------------------------------------------------------------------|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20231117/57d1bdbb/attachment.htm>