[tz] Extra transition for Europe/London with 2023d

Guy Harris gharris at sonic.net
Sat Jan 6 21:52:14 UTC 2024


On Jan 6, 2024, at 1:03 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 2024-01-06 12:45, Guy Harris via tz wrote:
>> there is no inherent reason why the TZif format, for example, should
>> limit itself to supporting only the date/time functions that POSIX and
>> the C standard currently happen to provide
> 
> Although an API *could* support deeper interrogation of TZif details, I doubt whether that'd be a good idea. The distinction between stdoff and tm_gmtoff is not always clear, any extra information you'd extract from the data could well be dubious (certainly there are dubious corners in this part of tzdata now), and improving tzdata and maintaining the result would require unnecessary work.
> 
> We saw an instance of this sort of thing in America/Nuuk last year. Before 2023d, summer 2023 was marked as daylight saving time, but 2023d changed that to standard time. Although nobody in the real world cared (because it didn't affect UTC offsets or even abbreviations), the change consumed nontrivial maintenance effort. And the only reason the change was needed was because of tm_isdst, a feature that should never have been made visible to users in the first place.
> 
> I wouldn't want even more unnecessary maintenance make-work to follow from exposing even more unnecessary details to users.

Perhaps exposing the stuff that, say, the java.time people want exposed would not be ideal...

...but they already work around the lack of that information in TZif files by reading the source files, so it's not as if not providing that information in TZif files prevents people from using information from the source files in ways that are, perhaps, unwise.  Perhaps generating JSON files from the source is the way to go there; that would, at least, let the source file format and contents not be constrained by code that uses them directly.

However, I'd still like to see what the people who use the source files to get STDOFF and SAVE information - and, for that matter, rule information - to give examples of how this is useful.


More information about the tz mailing list