[tz] Java & Rearguard

[Brian Inglis]

On 2019-06-11 19:50, Guy Harris wrote:
> On Jun 11, 2019, at 1:14 PM, Guy Harris wrote:
>> On Jun 11, 2019, at 1:51 AM, Andreas Schwab wrote:
>>> That's what the rest of the world calls summer time.
>> That's what the part of the world that turns their clocks forward in
>> spring and summer calls summer time.
> Or that's what the part of the world that turns their clocks forward in 
> spring and summer, with the exception of the US and (English-speaking?)
> Canada, calls "summer time".

Indeed; in French speaking North America, it's l'heure normale/avancée du
Pacifique/des Rocheuses/du Centre/de l'Est/de l'Atlantique/de Terre-Neuve
(HN/AP/R/C/E/A/T).
I imagine there are similar terms in Spanish for Mexico etc. and Portuguese for
Brazil etc.

> In any case, the point is that not all locales that do seasonal adjustment
> of time have "standard time" during the autumn and winter and "summer time" 
> during the spring and summer; they might have "standard time" during the
> spring and summer, as the Republic of Ireland does.

>> One API that the tzdb must support is the C localtime()/mktime() API.  As 
>> specified in ISO/IEC 9899:2011(E):

> Neither ISO/IEC 9899:2018(E) nor the most recent draft I've seen of ISO/IEC 9899:202x(E):
> 	http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2346.pdf
> say anything significantly different - they continue to speak of "Daylight 
> Saving Time", but leave it unspecified what it means, so as not to explicitly
> *disallow* it meaning something other than "temporarily turning clocks
> forward for spring and summer".

> Paul, would somebody have to be a member of the C standards committee, or 
> join their mailing list, in order to say "maybe the name 'Daylight Saving 
> Time'" should be removed, in favor of something that doesn't imply a
> seasonal change where the algorithm is change to turn clocks forward, given
> that the algorithm might be changed for reasons that aren't what's
> conventionally thought of as seasonal (e.g., Ramadan) or might be changed to
> turn clocks *backward* in the winter"?

There are certainly former, and possibly current, members of the standards
committees subscribed to this list, and may be participating in this thread
(hands up list subscribers who have not chimed in on this thread ;^> ).

Would also be an opportunity to extend TZ:
TZ=std offset dst [offset],start[/time],end[/time][,start[/time],end[/time]]...
where additional transition pairs could be added, better accommodating reality.

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

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.