[tz] Irish Standard Time vs Irish Summer Time

[Brian Inglis]

On 2018-01-22 11:10, Random832 wrote:
> On Sun, Jan 21, 2018, at 08:07, Robert Elz wrote:
>>   From: Paul Eggert <eggert at cs.ucla.edu>
>>   Date: Sat, 20 Jan 2018 12:49:01 -0800
>>   Subject: Re: [tz] Irish Standard Time vs Irish Summer Time
>>
>>   | An API standard could allow tm_zone to be either a char 
>>   | array or a char const * pointer,
>>
>> While it is obviously possible, I'd suggest not the array form --
>> coming up with something that is big enough to withstand possible
>> future abbreviations, without ABI problems, or being forced to
>> arbitrarily limit their lengths to meet the lowest common value of
>> what the various implementations have chosen would be just too hard
>> to live with.  (And having implementations make it be absurdly large,
>> like 128 or something, just in case, would be just plain wasteful.)
> 
> What about not directly exposing tm_zone at all? Just have a function that 
> takes a struct tm * and provides a timezone name string based on examining
> an implementation-defined selection of data members of the struct. [In fact,
> this function already exists and is called strftime.]
> 
> You could, for example, have the struct tm contain an integer identifier 
> (which won't be reused once the string is unloaded), and once the string is 
> "lifetimed out" the function will simply return UTC+NN:NN instead. The
> actual strings could live in a global data structure with the least recently
> used string freed whenever more space is needed.

Donwstream libraries seem to use either the BSD or GNU definitions of tm_gmtoff
and tm_zone, combined with localization using ICU, or their platform's approach.

While most distros distribute tzdata, few distribute tzcode, providing only zic
and zdump utilities.

Their upstream libraries use internationalization interfaces, and selectively
apply tzcode patches with their own variations to handle i18n and l14n.
These libraries and their data have been stable for decades, so it seems
unlikely that innovations impacting their core ABI would be adopted, as we have
seen with recent data changes.

>From recent data issues, we have seen that handling i14n and l14n compatibly
overrides legal correctness, and we should pay close attention to those concerns
expressed.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada