Fwd: New Version Notification for draft-murchison-rfc8536bis-06.txt
All, Here is the latest update to the TZif specification. Please give this a review and let us know if there are any errors or omissions. I'd like to start the process of getting this published as a new RFC, which will obsolete RFC 8536. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-06.txt Date: Tue, 07 Mar 2023 07:00:48 -0800 From: internet-drafts@ietf.org To: Arthur David Olson <arthurdavidolson@gmail.com>, Arthur Olson <arthurdavidolson@gmail.com>, Kenneth Murchison <murch@fastmailteam.com>, Paul Eggert <eggert@cs.ucla.edu> A new version of I-D, draft-murchison-rfc8536bis-06.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-rfc8536bis Revision: 06 Title: The Time Zone Information Format (TZif) Document date: 2023-03-07 Group: Individual Submission Pages: 46 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://author-tools.ietf.org/iddiff?url2=draft-murchison-rfc8536bis-06 Abstract: This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. The IETF Secretariat
And here is a link to the diffs between this draft and RFC 8536 <https://author-tools.ietf.org/diff?url_1=https://www.rfc-editor.org/rfc/rfc8...> On 3/7/23 10:03 AM, Ken Murchison wrote:
All,
Here is the latest update to the TZif specification. Please give this a review and let us know if there are any errors or omissions.
I'd like to start the process of getting this published as a new RFC, which will obsolete RFC 8536.
-------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-06.txt Date: Tue, 07 Mar 2023 07:00:48 -0800 From: internet-drafts@ietf.org To: Arthur David Olson <arthurdavidolson@gmail.com>, Arthur Olson <arthurdavidolson@gmail.com>, Kenneth Murchison <murch@fastmailteam.com>, Paul Eggert <eggert@cs.ucla.edu>
A new version of I-D, draft-murchison-rfc8536bis-06.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository.
Name: draft-murchison-rfc8536bis Revision: 06 Title: The Time Zone Information Format (TZif) Document date: 2023-03-07 Group: Individual Submission Pages: 46 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://author-tools.ietf.org/iddiff?url2=draft-murchison-rfc8536bis-06
Abstract: This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined.
This document replaces and obsoletes RFC 8536.
The IETF Secretariat
-- Kenneth Murchison Cyrus Development Team FastMail Pty Ltd
Ken Murchison wrote in <e90e1cbb-8882-2796-a4d2-153370128f4e@fastmailteam.com>: |And here is a link to the diffs between this draft and RFC 8536 |<https://author-tools.ietf.org/diff?url_1=https://www.rfc-editor.org/rfc\ |/rfc8536.txt&url_2=https://www.ietf.org/archive/id/draft-murchison-rfc85\ |36bis-06.txt> Thanks for this link. I wonder whether it would make sense to avoid the link to github? Ie, there is [EGGERT-TZ] "History for tz", October 2018, <https://github.com/eggert/tz/commits/master/tzfile.5> but since there is also [tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", 2018, <https://www.iana.org/time-zones/repository/tz-link.html>. (broken btw) i would rather linke these two into the latest release like [EGGERT-TZ] "History for tz", https://data.iana.org/time-zones/tzdb/tzfile.5.txt ... [tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", <https://data.iana.org/time-zones/tzdb/tz-link.html> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Quoting Steffen Nurpmeso via tz on Tuesday March 07, 2023:
[tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", 2018, <https://www.iana.org/time-zones/repository/tz-link.html>. (broken btw) ... <https://data.iana.org/time-zones/tzdb/tz-link.html>
Could you clarify what is broken so we can address it? (In our provisioning these files should contain identical content.) kim
Kim Davies wrote in <ZAelqdRsVySL5fIA@KIDA-9190.local>: |Quoting Steffen Nurpmeso via tz on Tuesday March 07, 2023: |> |> [tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and |> Daylight Saving Time Data", 2018, |> <https://www.iana.org/time-zones/repository/tz-link.html>. |> (broken btw) |> ... |> <https://data.iana.org/time-zones/tzdb/tz-link.html> | |Could you clarify what is broken so we can address it? (In our |provisioning these files should contain identical content.) $ curl -L -I https://www.iana.org/time-zones/repository HTTP/1.1 404 Not Found --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Steffen Nurpmeso wrote in <20230307210752.sR_ck%steffen@sdaoden.eu>: |Kim Davies wrote in | <ZAelqdRsVySL5fIA@KIDA-9190.local>: ||Quoting Steffen Nurpmeso via tz on Tuesday March 07, 2023: ||> ||> [tz-link] Eggert, P. and A. Olson, "Sources for Time Zone and ||> Daylight Saving Time Data", 2018, ||> <https://www.iana.org/time-zones/repository/tz-link.html>. ||> (broken btw) ||> ... ||> <https://data.iana.org/time-zones/tzdb/tz-link.html> || ||Could you clarify what is broken so we can address it? (In our ||provisioning these files should contain identical content.) | | $ curl -L -I https://www.iana.org/time-zones/repository | HTTP/1.1 404 Not Found Ah wait it was just me playing around with the URL: t$ curl -L -I https://www.iana.org/time-zones/repository/tz-link.html HTTP/1.1 302 Found ... HTTP/2 200 ... But nonetheless -- the /tzdb/ URL is fully accessible and allows people (like me) to snuffle around and explore TZDB in all its beauty. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Quoting Steffen Nurpmeso on Tuesday March 07, 2023:
|> <https://www.iana.org/time-zones/repository/tz-link.html>.
$ curl -L -I https://www.iana.org/time-zones/repository
That appears to me to be a different URL. https://www.iana.org/time-zones/repository/tz-link.html is functioning. If you wish to link to the main page, it would be https://www.iana.org/time-zones and https://iana.org/tz will work as a shortcut. kim
On 3/7/23 12:36, Steffen Nurpmeso via tz wrote:
I wonder whether it would make sense to avoid the link to github? Ie, there is
[EGGERT-TZ] "History for tz", October 2018, <https://github.com/eggert/tz/commits/master/tzfile.5>
That citation was intended to refer the reader to the history for tzfile.5, not just its current contents. This history is not so easily available on iana.org. At least we need to fix the citation by changing "master" to "main" in its URL. Thanks for pointing out the problem. Admittedly this is all a bit cryptic. Maybe some more wording in the citaion would also be helpful.
In rereading the draft I found a couple of technical issues. 1. Most of this draft was written before the recent announcement that leap seconds are possibly being discontinued. As I understand it, this proposal is likely but not yet set in stone. Perhaps we need a sentence or two about this in the draft? Something like the following at the first mention of leap second expiry: "If leap seconds become permanently discontinued, as requested by the General Conference on Weights and Measures[*], the leap second table SHOULD NOT expire since it will not be updated in the foreseeable future." and cite Resolution 4 of the 27th CGPM (2022) <https://www.bipm.org/en/cgpm-2022/resolution-4>. 2. The use of TZ strings like 'XXX3EDT4,0/0,J365/23' is described confusingly, since 3.3.1 says that this is not an extension to POSIX (i.e., we're just spelling out what POSIX says, so this is not a TZ string extension), whereas the title of 3.3.1 says "TZ String Extensions". Because section 4 says a writer should generate a version 3 file (which can contain TZ string extensions) only if necessary, it's too easy to read this as saying that if the TZif file contains a TZ string like 'XXX3EDT4,0/0,J365/23' then it must be at least version 3 - which is not how current zic behaves (it's just version 2). (This confusion is my fault; sorry.) To fix this, how about if we move the text and example in the bullet point "* DST is considered to be in effect all year ..." up from section 3.3.1 to section 3.3, with minor wordsmithing to continue to make it clear that we're only spelling out POSIX more explicitly, not extending it. As a result of this wordsmithing, there will only be one POSIX extension (extending hours to -167 through 167). I suppose we should also should note that a future version of POSIX is likely to adopt the POSIX extension documented in 3.3.1. Even if that happens, 3.3.1 will still considered to be an extension, in that TZif files using it will still need to be marked version 3 or later.
Attached is the diff between my working copy and -06. Comments and suggested text welcome. I wonder if we need to add a definition of "leap second table expiration". On 3/7/23 5:59 PM, Paul Eggert wrote:
In rereading the draft I found a couple of technical issues.
1. Most of this draft was written before the recent announcement that leap seconds are possibly being discontinued. As I understand it, this proposal is likely but not yet set in stone. Perhaps we need a sentence or two about this in the draft? Something like the following at the first mention of leap second expiry:
"If leap seconds become permanently discontinued, as requested by the General Conference on Weights and Measures[*], the leap second table SHOULD NOT expire since it will not be updated in the foreseeable future."
and cite Resolution 4 of the 27th CGPM (2022) <https://www.bipm.org/en/cgpm-2022/resolution-4>.
2. The use of TZ strings like 'XXX3EDT4,0/0,J365/23' is described confusingly, since 3.3.1 says that this is not an extension to POSIX (i.e., we're just spelling out what POSIX says, so this is not a TZ string extension), whereas the title of 3.3.1 says "TZ String Extensions". Because section 4 says a writer should generate a version 3 file (which can contain TZ string extensions) only if necessary, it's too easy to read this as saying that if the TZif file contains a TZ string like 'XXX3EDT4,0/0,J365/23' then it must be at least version 3 - which is not how current zic behaves (it's just version 2). (This confusion is my fault; sorry.)
To fix this, how about if we move the text and example in the bullet point "* DST is considered to be in effect all year ..." up from section 3.3.1 to section 3.3, with minor wordsmithing to continue to make it clear that we're only spelling out POSIX more explicitly, not extending it. As a result of this wordsmithing, there will only be one POSIX extension (extending hours to -167 through 167).
I suppose we should also should note that a future version of POSIX is likely to adopt the POSIX extension documented in 3.3.1. Even if that happens, 3.3.1 will still considered to be an extension, in that TZif files using it will still need to be marked version 3 or later.
-- Kenneth Murchison Cyrus Development Team FastMail Pty Ltd
On 2023-03-08 07:50, Ken Murchison via tz wrote:
Attached is the diff between my working copy and -06. Comments and suggested text welcome. I wonder if we need to add a definition of "leap second table expiration". On 3/7/23 5:59 PM, Paul Eggert wrote:
In rereading the draft I found a couple of technical issues. 1. Most of this draft was written before the recent announcement that leap seconds are possibly being discontinued. As I understand it, this proposal is likely but not yet set in stone. Perhaps we need a sentence or two about this in the draft? Something like the following at the first mention of leap second expiry: "If leap seconds become permanently discontinued, as requested by the General Conference on Weights and Measures[*], the leap second table SHOULD NOT expire since it will not be updated in the foreseeable future." and cite Resolution 4 of the 27th CGPM (2022) <https://www.bipm.org/en/cgpm-2022/resolution-4>. 2. The use of TZ strings like 'XXX3EDT4,0/0,J365/23' is described confusingly, since 3.3.1 says that this is not an extension to POSIX (i.e., we're just spelling out what POSIX says, so this is not a TZ string extension), whereas the title of 3.3.1 says "TZ String Extensions". Because section 4 says a writer should generate a version 3 file (which can contain TZ string extensions) only if necessary, it's too easy to read this as saying that if the TZif file contains a TZ string like 'XXX3EDT4,0/0,J365/23' then it must be at least version 3 - which is not how current zic behaves (it's just version 2). (This confusion is my fault; sorry.) To fix this, how about if we move the text and example in the bullet point "* DST is considered to be in effect all year ..." up from section 3.3.1 to section 3.3, with minor wordsmithing to continue to make it clear that we're only spelling out POSIX more explicitly, not extending it. As a result of this wordsmithing, there will only be one POSIX extension (extending hours to -167 through 167). I suppose we should also should note that a future version of POSIX is likely to adopt the POSIX extension documented in 3.3.1. Even if that happens, 3.3.1 will still considered to be an extension, in that TZif files using it will still need to be marked version 3 or later.
Suggest using alternative rather than Daylight Savings Time as under current POSIX Base Definitions 8.3 Other Environment Variables TZ: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag... "std and dst Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the alternative (dst -such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale."... as the alternative can be positive or negative (Ireland) and outside English North America, is mostly referred to as Summer or Winter time, or some equivalent expression in the local language, often advanced, normal, or retarded time in Latin languages e.g. NRC/CNR pubs for French Canada for an alternative: https://nrc.canada.ca/fr/certifications-evaluations-normes/heure-officielle-... [default size may be large - <ctrl>-0 often normalizes!] -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Brian Inglis via tz wrote in <59c06905-1bba-d3da-85db-7f1d84cf8472@Shaw.ca>: |On 2023-03-08 07:50, Ken Murchison via tz wrote: |> Attached is the diff between my working copy and -06. Comments and \ |> suggested |> text welcome. ... |Suggest using alternative rather than Daylight Savings Time as under \ |current |POSIX Base Definitions 8.3 Other Environment Variables TZ: | |https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html\ |#tag_08_03 | |"std and dst |Indicate no less than three, nor more than {TZNAME_MAX}, bytes that \ |are the |designation for the standard (std) or the alternative (dst -such as \ |Daylight |Savings Time) timezone. Only std is required; if dst is missing, then the |alternative time does not apply in this locale."... I _think_ this is objected by kre and fine-tuning is on the way? (I am not really looking into this issue. I never dealt with these strings, but only ever used identifiers.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 2023-03-09 10:28, Steffen Nurpmeso wrote:
Brian Inglis wrote: |On 2023-03-08 07:50, Ken Murchison wrote: |> Attached is the diff between my working copy and -06. Comments and \ |> suggested |> text welcome. ... |Suggest using alternative rather than Daylight Savings Time as under \ |current |POSIX Base Definitions 8.3 Other Environment Variables TZ: | |https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html\ |#tag_08_03 | |"std and dst |Indicate no less than three, nor more than {TZNAME_MAX}, bytes that \ |are the |designation for the standard (std) or the alternative (dst -such as \ |Daylight |Savings Time) timezone. Only std is required; if dst is missing, then the |alternative time does not apply in this locale."...
I _think_ this is objected by kre and fine-tuning is on the way? (I am not really looking into this issue. I never dealt with these strings, but only ever used identifiers.)
POSIX is kre et al and this wording is already in use, and I do not remember seeing any edits to this in reports. The RFC addressed is IANA/IETF by the poster, including PE and ADO, so I suggest the wording and usage be aligned for accuracy and clarity. I would also be nice if TZ abbreviations and TZ or zone identifiers were used to describe what are sometimes both confusingly called TZ names. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Date: Thu, 09 Mar 2023 18:28:27 +0100 From: Steffen Nurpmeso via tz <tz@iana.org> Message-ID: <20230309172827.kzxkJ%steffen@sdaoden.eu> | I _think_ this is objected by kre and fine-tuning is on the way? I believe Brian's comment was purely related to the use of the phrase "Daylight Savings Time", suggesting the (current, and unlikely to alter) POSIX phrase "alternative timezone" as a replacement. Nothing I am sending POSIX bug reports about is related to this. Though perhaps I should - as "alternative" suggests just one other possibility, standard time, and the other time, and that's not really sufficient (it is OK with a POSIX defined TZ string, as those can only handle two offsets - the standard one, and an alternative). In reality, all local time is "standard time" - the offset of that from UTC varies during the year in many jurisdictions, but be it summer or winter, it is still the standard time. The idea that one is right, and the other is different, is nonsense. If we went back to pure solar time, (it is 12:00 noon, when the sun is at the highest point for the day, all other times are relative to that) then we could perhaps call that the "real" time, and any variations as just that. But that's not going to happen - needing to adjust your watch (a tiny bit) if you move from the east side of a room to the west side is unimplementable. But without a rule like that, all time is simply whatever we decide it should be, nothing is more right, or more wrong, than anything else (though of course there are lots of people who believe what they were taught as a child is infallible, and any variation on that is heresy). Whatever correctly adjusted local clocks show is the local standard time. That's what being "standard" means. How to describe all of this in the various places it should be described I don't know - but I certainly agree that imagining that there is "standard" and "daylight saving" time and using those as if they name different kinds of local time is not a good idea. I do however understand the need, by those who support it, to sell the ideas to the mostly ignorant general public, who actually believe there is one true correct proper time (which is in accordance with what they grew up with believing was that one true time) rather than the offset being simply a matter of convenience which can be changed (at some cost) whenever the benefits are believed to outweigh those costs, and none of this will cause the world to fall in. Telling the masses that there is going to be a brief period of alteration, with a special name, from their one true known correct time allows people to accept it, where if told the one true time was going to be altered, you'd have a revolt - even though what happens is 100% identical in the two cases, but with different rhetoric. Apologies for the rant... Lots of the way this is all approached bugs me, as it makes no logical sense at all. kre
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.
On Mar 9, 2023, at 2:34 PM, Paul Eggert via tz <tz@iana.org> wrote:
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).
Neither of which correspond to time zones in this sense of the word, which may be what many (most?) people think of when they hear "time zone": https://en.wikipedia.org/wiki/Time_zone#/media/File:World_Time_Zones_Map.png as: 1) the non-adjusted TZ offset might correspond to that sort of time zone, but not all locations within that sort of time zone necessarily use the same abbreviation (or have the same rules for adjusting the TZ offset if they adjust it), so that doesn't correspond to a POSIX "timezone" and 2) over and above what's in 1), a given tzdb Zone may move between time zones in that sense, so it corresponds even *less* to a tzdb Zone. That's why I tend to refer to tzdb Zones as "tzdb regions" rather than anything containing the word "zone".
On 3/8/23 06:50, Ken Murchison wrote:
I wonder if we need to add a definition of "leap second table expiration".
That wouldn't hurt. Perhaps something like the following in the Section 2 definitions? ----- Leap Second Table: A record of a series of consecutive leap seconds. Leap Second Table Expiration: The cutoff time for a leap second table, such that the table does not record the presence or absence of leap seconds on or after the cutoff. For example, a leap second table published in January, which predicts the presence or absence of a leap second at June's end, might expire in mid-December because when the table is published it is not known whether a leap second will occur at December's end. ----- PS. I see that the draft sometimes says "leap second" and sometimes "leap-second". I assume that follows some editorial rule that I don't remember. The above text might need hyphenization to fix that.
On 2023-03-09 4:30 PM, Paul Eggert via tz wrote:
PS. I see that the draft sometimes says "leap second" and sometimes "leap-second". I assume that follows some editorial rule that I don't remember. The above text might need hyphenization to fix that. ITU-R Recommendation 460, the specification of the leap-second, spells "leap-second" with the hyphen. I feel that's the "proper" spelling because it comes from the ITU-R document.
Brooks Harris replied to Paul Eggert:
PS. I see that the draft sometimes says "leap second" and sometimes "leap-second". I assume that follows some editorial rule that I don't remember. The above text might need hyphenization to fix that.
ITU-R Recommendation 460, the specification of the leap-second, spells "leap-second" with the hyphen. I feel that's the "proper" spelling because it comes from the ITU-R document.
Most usage in American English, outside of standards documents, trends toward “leap second,“ just as it trends toward “leap year” rather than “leap-year.” The general rule (again in American English) is to spell a compound like this as two words when using it as an ordinary noun, but hyphenate it when using it as an attributive noun. So you would have “leap-second rules” that determine the application of “leap seconds.” The attributive-noun convention (see what I did there?) is helpful to disambiguate phrases that contain long strings of nouns. See https://en.wikipedia.org/wiki/English_compound for more. ITU-R English is often not common, idiomatic American English, so your priorities may differ if you need to follow European English (or if you prefer old-fashioned usage, as in the base-ball game to be played to-day). -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On 2023-03-09 4:57 PM, Doug Ewell via tz wrote:
Brooks Harris replied to Paul Eggert:
PS. I see that the draft sometimes says "leap second" and sometimes "leap-second". I assume that follows some editorial rule that I don't remember. The above text might need hyphenization to fix that. ITU-R Recommendation 460, the specification of the leap-second, spells "leap-second" with the hyphen. I feel that's the "proper" spelling because it comes from the ITU-R document. Most usage in American English, outside of standards documents, trends toward “leap second,“ just as it trends toward “leap year” rather than “leap-year.” OK. I'm typically thinking of "standards documents" and in the context of tzdb we are often speaking in "standards" terms. Is "leap second" *exactly* the same as "leap-second"? I'm not as concerned with "American English" v.s. some other "English" and I'm surely not an expert in such distinctions. I hope for technical clarity in this arena. As I said, I *feel* "leap-second" with hyphen is the most clear because it comes from the source document. How its used in tzdb specs or documentation is a choice contributors can make.
Thanks, -Brooks
The general rule (again in American English) is to spell a compound like this as two words when using it as an ordinary noun, but hyphenate it when using it as an attributive noun. So you would have “leap-second rules” that determine the application of “leap seconds.” The attributive-noun convention (see what I did there?) is helpful to disambiguate phrases that contain long strings of nouns.
See https://en.wikipedia.org/wiki/English_compound for more.
ITU-R English is often not common, idiomatic American English, so your priorities may differ if you need to follow European English (or if you prefer old-fashioned usage, as in the base-ball game to be played to-day).
-- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Thu 2023-03-09T13:30:52-0800 Paul Eggert via tz hath writ:
Leap Second Table: A record of a series of consecutive leap seconds.
Leap Second Table Expiration: The cutoff time for a leap second table, such that the table does not record the presence or absence of leap seconds on or after the cutoff. For example, a leap second table published in January, which predicts the presence or absence of a leap second at June's end, might expire in mid-December because when the table is published it is not known whether a leap second will occur at December's end.
Be aware that this six month expiration cycle is a leftover from the Soviet demands at the inception of leap-seconds and is not explicit in any regulatory document. It is tradition, albeit long established. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
On 2023-03-09 14:59, Steve Allen wrote:
On Thu 2023-03-09T13:30:52-0800 Paul Eggert hath writ:
Leap Second Table: A record of a series of consecutive leap seconds.
Leap Second Table Expiration: The cutoff time for a leap second table, such that the table does not record the presence or absence of leap seconds on or after the cutoff. For example, a leap second table published in January, which predicts the presence or absence of a leap second at June's end, might expire in mid-December because when the table is published it is not known whether a leap second will occur at December's end.
Be aware that this six month expiration cycle is a leftover from the Soviet demands at the inception of leap-seconds and is not explicit in any regulatory document. It is tradition, albeit long established.
Possibly a government which understands the realistic limitations of its, and others, bureaucracies; rather than one which expects its petulant last minute demands be immediately satisfied by everyone else in the world affected slaving tirelessly to offset their inability to think and plan six months ahead. ;^> [OTOH I worked on a project where the org took until the project development deadline a year later to decide which set of rules it followed^Wwanted to follow^Wchose to pick^Wneeded to use, all of which had to be implemented, tested, and deployment tested with all options, so they could decide at the last minute, and also throw in some other demands which blew their own deadline!] -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
participants (10)
-
Brian Inglis -
Brooks Harris -
Doug Ewell -
Guy Harris -
Ken Murchison -
Kim Davies -
Paul Eggert -
Robert Elz -
Steffen Nurpmeso -
Steve Allen