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

[Guy Harris]

On Nov 17, 2023, at 12:29 PM, Fred Gleason via tz <tz at iana.org> wrote:
> 
> 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

Are there any people in Ireland who believe that "Daylight Saving Time" is observed during the winter?

If not, there does not appear to be any divergence of understanding mourned what "Daylight Saving Time" means between Ireland and North America.

As per my earlier mail, at least two web sites in Ireland

	https://www.abcschoolsupplies.ie/why-do-the-clocks-change

and

	https://safetymatters.ie/news/daylight-saving-time-dst-is-related-to-health-and-safety-in-several-ways/

appear to use "Daylight Saving Time" to refer to what's in effect during the summer.

Where Ireland diverges from North America and, as far as I know, the rest of Europe is that "standard time" is, in Ireland, the time observed during the summer, rather than the time observed during the winter, as is the case in North America and the rest of Europe.

> 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? 

Presumably you mean "persuading the maintainers of the C standard, POSIX standard, and systems that provide implementations of localtime() to set tm_isdst to -1 in all zones that do not return a fixed offset for the entire year".

Yes, that would be the ideal, although you may get pushback from software developers who use that field under the assumption that it tells them something about the time being converted, even if what it tells them isn't necessarily what they think it tells them.

> 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:

That got deprecated, in those operating systems that provided gettimeofday() and settimeofday(), as those operating systems switched from using the "struct timezone" information to convert between system time and local time to using the tzdb.  SunOS did that in 4.0; I think the Berkeley Software Distribution did so at one point.

And the vast majority of the code that use the "struct timezone" information was in a library called the "C library", in a routine called "localtime()", so the set of code that cared about that structure was probably very small and straightforward to change - some people, I forget who, even put out a reference implementation of localtime() that used the tzdb, which could be used as a replacement. :-)

Deprecating tm_isdst might be more work - for one thing, the aforementioned localtime() is what *provides* it.