[tz] Fwd: New Version Notification for draft-murchison-rfc8536bis-06.txt

[Paul Eggert]

On 3/9/23 08:30, Brian Inglis via tz wrote:
> Suggest using alternative rather than Daylight Savings Time as under 
> current POSIX

Current POSIX is confused about this, as it uses "alternative time" or 
"alternative timezone" for this concept (e.g., in its description of the 
TZ variable), but it also uses "alternative time" to mean something 
quite different in functions like strftime which deal with locale 
alternative time representations. Furthermore POSIX often uses "Daylight 
Savings Time" with an "s" (e.g., in its description of time.h, or in 
functions like mktime) to mean the same thing as "alternative time", and 
at least once it omits the "s" (in a strptime example).

Contrast this with ISO C, which constently uses "Daylight Saving Time" 
(without the "s") for the same notion.

Also contrast POSIX's use of the word "timezone" (meaning just an 
abbreviation and a UT offset) with TZDB's use (meaning a tzdb Zone, 
something more complicated). POSIX doesn't seem to be consistent about 
this usage, though: often "timezone" seems to mean the entire contents 
of the TZ variable, which is closer to TZDB's meaning.

Furthermore, POSIX uses the term "standard time" the same way that RFC 
8536 does, but as far as I can see ISO C has no name for that concept.

Fun stuff, no?

With this confusion in mind, it might be better for RFC 8536 to stick 
with its current terms "standard time" and "daylight saving time". It'd 
take nontrivial wordsmithing to change the terminology, with some errors 
likely to creep in during the process, and it's not clear that the 
benefits would be worth the costs.

Admittedly (and as Robert noted), the phrases "standard time" and 
"daylight saving time" are poorly chosen. DST obviously doesn't save any 
daylight; and a government-mandated standard for civil time includes 
"daylight saving time" as well as "standard time". However, I'm not sure 
it's worth the hassle to try to improve on these phrases in RFC 8536, 
especially considering what we've seen of POSIX's problems in its 
attempts to use a different terminology.