Subject: [Tzdist-bis] Fwd: New Version Notification for draft-murchison-tzdist-tzif-06.txt

From: Ken Murchison <[email-masked]>
Date: Fri, 15 Jun 2018 18:30:18 -0400

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-murchison-tzdist-tzif-06.txt
Date: 	Fri, 15 Jun 2018 15:28:46 -0700
From: 	[email-masked]
To: 	Arthur David Olson <[email-masked]>, Paul Eggert 
<[email-masked]>, Ken Murchison <[email-masked]>, Arthur 
Olson <[email-masked]>, Kenneth Murchison 
<[email-masked]>

A new version of I-D, draft-murchison-tzdist-tzif-06.txt
has been successfully submitted by Kenneth Murchison and posted to the
IETF repository.

Name:		draft-murchison-tzdist-tzif
Revision:	06
Title:		The Time Zone Information Format (TZif)
Document date:	2018-06-15
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-murchison-tzdist-tzif-06.txt
Status:         https://datatracker.ietf.org/doc/draft-murchison-tzdist-tzif/
Htmlized:       https://tools.ietf.org/html/draft-murchison-tzdist-tzif-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-murchison-tzdist-tzif
Diff:           https://www.ietf.org/rfcdiff?url2=draft-murchison-tzdist-tzif-06

Abstract:
    This document defines the Time Zone Information Format (TZif) for
    representing and exchanging time zone information, independent of any
    particular service or protocol.  A MIME media type for this format is
    also defined.

Open Issues

    o  Should we require TZDIST servers to always return a particular
       format (2 or 3) with/without leap seconds?  Or should we allow the
       client to choose what they want (via parameters on the MIME type)?
       E.g. application/tzif+leap; version=3

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jun 2018 10:07:56 -0700

>       E.g. application/tzif+leap; version=3

Not sure just how you intend client behavior.  There are two choices:
mime/multipart or Accept: headers.  What is the argument for not
choosing a single approach?

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 10:35:45 -0700

A few other points.

First, zic currently outputs version 2 format if the data fit into version 2, 
and outputs version 3 format only if the data need features in version 3 but not 
version 2. (zic no longer outputs version 1 format.) If a client were to request 
version 3 data, it should be OK to respond with version 2 data if that's what 
zic generated, as it'll work fine and it contains all the info that version 3 would.

Second, the formats are typically forwards-compatible. That is, old clients 
designed only for version 1 data can still read version 2 or 3 data and they 
will typically (albeit not invariably) work as well as they worked with version 
1 data. Similarly, clients designed for version 2 data not only can read version 
1 data just fine, they also typically (albeit not invariably) work just as well 
with version 3 data as they do with version 2 data. And clients designed for 
version 3 data can read the older versions just fine.

Third, almost nobody uses data with leap seconds. The vast majority of clients 
want POSIX time, not "right" time.

With that in mind, I expect most clients to accept data of any of the three 
versions and to prefer the newest version available, and to want only POSIX 
time. A few clients may want both POSIX and "right" time (I assume as 
mime/multipart?) or even to want just "right" time. No client will want the same 
data in two different versions.

I hope these comments help to clarify what should be in Accept: headers.

---

From: Matthew Donadio <[email-masked]>
Date: Sat, 16 Jun 2018 13:43:22 -0400

On Sat, Jun 16, 2018 at 1:07 PM, Eliot Lear <lear=[email-masked]
> wrote:

> choosing a single approach?

Some caches/CDNs and proxies don't handle content negotiation properly with
the Accept header, and will serve up the incorrect response.

--Matthew Donadio ([email-masked])

---

From: Ken Murchison <[email-masked]>
Date: Sat, 16 Jun 2018 13:49:56 -0400

On 06/16/2018 01:35 PM, Paul Eggert wrote:
> A few other points.
>
> First, zic currently outputs version 2 format if the data fit into 
> version 2, and outputs version 3 format only if the data need features 
> in version 3 but not version 2. (zic no longer outputs version 1 
> format.) If a client were to request version 3 data, it should be OK 
> to respond with version 2 data if that's what zic generated, as it'll 
> work fine and it contains all the info that version 3 would.
>
> Second, the formats are typically forwards-compatible. That is, old 
> clients designed only for version 1 data can still read version 2 or 3 
> data and they will typically (albeit not invariably) work as well as 
> they worked with version 1 data. Similarly, clients designed for 
> version 2 data not only can read version 1 data just fine, they also 
> typically (albeit not invariably) work just as well with version 3 
> data as they do with version 2 data. And clients designed for version 
> 3 data can read the older versions just fine.
>
> Third, almost nobody uses data with leap seconds. The vast majority of 
> clients want POSIX time, not "right" time.
>
> With that in mind, I expect most clients to accept data of any of the 
> three versions and to prefer the newest version available, and to want 
> only POSIX time. A few clients may want both POSIX and "right" time (I 
> assume as mime/multipart?) or even to want just "right" time. No 
> client will want the same data in two different versions.
>

GIven Paul's comments, I'm wondering if the version and leap seconds 
open issues are non-issues.

- We could recommend (SHOULD) or require (MUST) that servers return 
version 2 or 3.

- We can avoid discussing whether leap seconds need to be included in 
TZif, since TZDIST has its own facility for a client to fetch leap seconds.

If we determine that clients may want to fetch TZif files with leap 
seconds included, then we can define application/tzif+leap as a MIME 
type that servers can advertise in capabilities and clients can use in 
the Accept header.  If the server doesn't have leap second data or can't 
generate TZif with leap seconds, it can respond with 415.

Thoughts?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Sat, 16 Jun 2018 13:56:28 -0400

On 06/16/2018 01:49 PM, Ken Murchison wrote:
>> version 2, and outputs version 3 format only if the data need 
>> features in version 3 but not version 2. (zic no longer outputs 
>> version 1 format.) If a client were to request version 3 data, it 
>> should be OK to respond with version 2 data if that's what zic 
>> generated, as it'll work fine and it contains all the info that 
>> version 3 would.
>>
>> clients designed only for version 1 data can still read version 2 or 
>> 3 data and they will typically (albeit not invariably) work as well 
>> as they worked with version 1 data. Similarly, clients designed for 
>> Third, almost nobody uses data with leap seconds. The vast majority 
>> of clients want POSIX time, not "right" time.
>>
>> three versions and to prefer the newest version available, and to 
>> want only POSIX time. A few clients may want both POSIX and "right" 
>> time (I assume as mime/multipart?) or even to want just "right" time. 
>> No client will want the same data in two different versions.
>>
> the Accept header.  If the server doesn't have leap second data or 
> can't generate TZif with leap seconds, it can respond with 415.
>
> Thoughts?

One other option.  If the TZDIST server advertises leap seconds in 
capabilities, then the TZif files ALWAYS include leap seconds, otherwise 
they don't.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jun 2018 11:25:21 -0700

CCing the expert (Ned) to check my logic.

I think versioning in the MIME media type should be considered a
non-issue for the simple reason that the versioning is already integral
to the file format, and there is sufficient forward and backward
compatibility.  I don't know if it is perfect forward compatibility, but
it is darn sure close enough.

As to leap seconds, my suggestion is that since TZDIST handles them, so
long as it is clear to the parsing implementation that absence of leap
seconds means that they're simply not present, and not that there aren't
any, then to me we needn't address this matter in this specification,
other than to say just that.

This only leaves one issue.  What happens if v4 doesn't want to be
backward or forward compatible?  IMHO this would require that either the
versioning be externalized into a parameter in the media-type or that a
new media-type be procured.  Here some amount of prognostication is
required.  My argument: media-types are cheap.  On the off chance that
there is an incompatible change, they should just procure a new one.

As to Ken's later point about requiring leap seconds be included when
the capability is advertised, I am nervous about that in terms of
overloading an existing operator.  Suppose leap seconds can be retrieved
via TZDIST but are not in the zic output: does that mean that the
capability cannot be advertised at all?  If we want to advertise a
capability for zic'd leap seconds, I'd like it to have a new name, and
I'm not convinced it is required.

Eliot

---

From: Ken Murchison <[email-masked]>
Date: Sat, 16 Jun 2018 14:44:44 -0400

> I'm not convinced it is required.

On second thought, I agree with you, that overloading the TZDIST 
leapseconds capability is a non-starter.

I think a separate (or parameterized) MIME type to indicate TZif 
including leap seconds is the way to go, if we determine that its required.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Lester Caine <[email-masked]>
Date: Sat, 16 Jun 2018 20:02:48 +0100

> TZif, since TZDIST has its own facility for a client to fetch leap seconds.

The question is if the binary data is provided with or without leap 
seconds? One of the reasons for switching to a different base to 
eliminate the problem? Since TZDIST does not provide seconds based data, 
there is not a problem, but if TZif is biased with leap seconds, then 
the same version of leap second data needs to be married up to it ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Ken Murchison <[email-masked]>
Date: Sat, 16 Jun 2018 15:17:03 -0400

On 06/16/2018 03:02 PM, Lester Caine wrote:
> eliminate the problem? Since TZDIST does not provide seconds based 
> data, there is not a problem, but if TZif is biased with leap seconds, 
> then the same version of leap second data needs to be married up to it 
> ...

Agreed.  In the case of my TZDIST implementation, I generate TZif from 
iCalendar and add in leap-seconds.list

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 12:18:04 -0700

Ken Murchison wrote:
> 
> - We could recommend (SHOULD) or require (MUST) that servers return version 2 or 3.

We already say servers SHOULD NOT generate version 1. If we wanted to strengthen 
it, we could change it to MUST NOT (though in that case, why are we specifying 
version 1 at all?).

Come to think of it, regardless of whether we change that SHOULD NOT to MUST 
NOT, we should strengthen a later SHOULD to recommend that servers generate 
version 3 files if the underlying data need version 3 features. That is, we 
should change this:

"Implementations SHOULD generate version 2 or 3 files."

to something like the following (sorry if it is too wordy, maybe you can trim it 
down):

"Implementations SHOULD generate version 2 or 3 files, and SHOULD generate 
version 3 files for data where version 3 can represent more time changes than 
version 2. For example, if the TZ string in the footer is 
'PST8PDT,M3.2.0,M11.1.0' (US Pacific time) an implementation SHOULD generate 
either version 2 or 3, whereas if the TZ string is 
'<-03>3<-02>,M3.5.0/-2,M10.5.0/-1' (Nuuk time) the implementation SHOULD 
generate version 3 since this TZ string has negative times-of-day, a version 3 
extension."

> - We can avoid discussing whether leap seconds need to be included in TZif, 
> since TZDIST has its own facility for a client to fetch leap seconds.
> 
> 
> If we determine that clients may want to fetch TZif files with leap seconds 
> included, then we can define application/tzif+leap as a MIME type that servers 
> can advertise in capabilities and clients can use in the Accept header.  If the 
> server doesn't have leap second data or can't generate TZif with leap seconds, 
> it can respond with 415.
> 
> Thoughts?

application/tzif+leap sounds like a reasonable thing.

One more thing I perhaps should mention. It's common on platforms with tzdata + 
leap seconds to use the "right/" prefix to specify leap seconds. For example, on 
both Debian and Fedora, TZ='right/America/Los_Angeles' is equivalent to 
TZ='America/Los_Angeles' except that it uses TAI (minus 10) as origin instead of 
using UTC. However, this behavior is certainly not universal: it's not in the 
reference implementation, and it's not in macOS or Solaris.

---

From: Guy Harris <[email-masked]>
Date: Sat, 16 Jun 2018 12:26:02 -0700

On Jun 16, 2018, at 12:18 PM, Paul Eggert <[email-masked]> wrote:

> One more thing I perhaps should mention. It's common on platforms with tzdata + leap seconds to use the "right/" prefix to specify leap seconds. For example, on both Debian and Fedora, TZ='right/America/Los_Angeles' is equivalent to TZ='America/Los_Angeles' except that it uses TAI (minus 10) as origin instead of using UTC. However, this behavior is certainly not universal: it's not in the reference implementation, and it's not in macOS or Solaris.

I.e., Debian and Fedora's "right/" TZif files have transition times represented as seconds that have elapsed since whatever "midnight, January 1, 1970, TAI" is called, rather than as, for example, seconds that have elapsed since midnight, January 1, 1970 UTC (not to be confused with "seconds since the Epoch", as "seconds since the Epoch" doesn't count leap seconds that have elapsed)?

Does the reference implementation use seconds that have elapsed since midnight, January 1, 1970 UTC (even if some of those seconds are leap seconds)?

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 13:08:04 -0700

> Does the reference implementation use seconds that have elapsed since midnight, January 1, 1970 UTC (even if some of those seconds are leap seconds)?

Yes, the original idea with the reference implementation (when leap seconds are 
enabled) is that the system clock ticks once every TAI second, i.e., that the 
POSIX 'time' function counts TAI (not POSIX) seconds. Thus, for example, if my 
computer is set up that way and the current Los Angeles time is 12:53:31, I 
would normally use the equivalent of TZ='right/America/Los_Angeles' to get the 
correct local time, and if I use TZ='posix/America/Los_Angeles' the time will be 
reported (incorrectly) as 12:53:58 because 27 positive leap seconds have 
occurred since 1960.

In practice, though, almost all computers keep POSIX time internally. As an 
example of this more-typical case, if my computer is set up to use POSIX time 
and the current time is 12:53:31,  I would normally use the equivalent of 
TZ='posix/America/Los_Angeles' to get the correct local time, and if I use 
TZ='right/America/Los_Angeles' the time will be reported as 12:53:04 because the 
correction will be applied in the opposite way.

The reference implementation also has functions time2posix_z and posix2time_z 
that let you convert TAI counts to POSIX counts and vice versa; these functions 
use the leap second info in the TZif file corresponding to their timezone argument.

---

From: Ken Murchison <[email-masked]>
Date: Sat, 16 Jun 2018 16:17:02 -0400

This whole discussion brings me to a question I've had for a while, 
which is why are the leap seconds, which I assume are universal, stuffed 
into every TZif file?  And twice?  Why aren't they kept in a separate 
file, or even as a separate "time zone"?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Guy Harris <[email-masked]>
Date: Sat, 16 Jun 2018 13:22:30 -0700

On Jun 16, 2018, at 1:08 PM, Paul Eggert <[email-masked]> wrote:

> Yes, the original idea with the reference implementation (when leap seconds are enabled) is that the system clock ticks once every TAI second, i.e., that the POSIX 'time' function counts TAI (not POSIX) seconds.

I.e., a TZif file that includes leap second information contains transition times and leap second times that are values of the sort that would be generated by a (non-POSIX-compliant) time() that counts TAI seconds that have elapsed since January 1, 1970, 00:00:00 UTC?

So how does this differ from what "right/" files from Debian and Fedora contain?  Do they, for example, contain transition times and leap second times that are values of the sort that would be generate by a (non-POSIX-compliant) time() that counts TAI seconds that have elapsed since 10 seconds before January 1, 1970, 00:00:00 UTC?

> In practice, though, almost all computers keep POSIX time internally. As an example of this more-typical case, if my computer is set up to use POSIX time and the current time is 12:53:31,  I would normally use the equivalent of TZ='posix/America/Los_Angeles' to get the correct local time, and if I use TZ='right/America/Los_Angeles' the time will be reported as 12:53:04 because the correction will be applied in the opposite way.

Is there any reason why one would use information from a "right/" TZif file to covert times generated by a POSIX-compliant time() that counts "seconds since the Epoch"?  My assumption would be that "posix/" files would always be used to convert times from a POSIX-compliant time() and never used to convert times from a "counts TAI seconds that have elapsed since the Epoch" time(), and that "right/" files would always be used to convert times from a "counts TAI seconds that have elapsed since the Epoch" time() and never used to convert times from a POSIX-compliant time().

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 14:58:07 -0700

> I.e., a TZif file that includes leap second information contains transition times and leap second times that are values of the sort that would be generated by a (non-POSIX-compliant) time() that co…

Yes, that's the idea.

> So how does this differ from what "right/" files from Debian and Fedora contain?

It doesn't. They're the same thing. At least, that's the intent.

> Do they, for example, contain transition times and leap second times that are values of the sort that would be generate by a (non-POSIX-compliant) time() that counts TAI seconds that have elapsed since 10 seconds before January 1, 1970, 00:00:00 UTC?

No, the "right" time() has the same origin as the POSIX time(). The "posix" and 
"right" clocks agree for all timestamps before the first leap second in 1972.

> Is there any reason why one would use information from a "right/" TZif file to covert times generated by a POSIX-compliant time() that counts "seconds since the Epoch"?

It wouldn't be typical, no. The only reason I can think of offhand, is if one 
wants to count leap seconds when the only API is the traditional POSIX 
setenv/tzset/localtime API. One can temporarily set 
TZ='right/America/Los_Angeles', invoke localtime, then set 
TZ='posix/America/Los_Angeles', invoke localtime again, and then subtract the 
resulting struct tm values. Admittedly this is not the most efficient way to 
compute leap seconds, but it does have the advantage of using the standard API.

> My assumption would be that "posix/" files would always be used to convert times from a POSIX-compliant time() and never used to convert times from a "counts TAI seconds that have elapsed since the Epoch" time(), and that "right/" files would always be used to convert times from a "counts TAI seconds that have elapsed since the Epoch" time() and never used to convert times from a POSIX-compliant time().

Yes, that's the ordinary use of these files. Though I would put it more 
strongly: almost everybody uses POSIX time and the "right/" files are in 
practice not used. In many implementations (e.g., FreeBSD, macOS, Solaris) the 
"right/" files are omitted. In others (Debian, Red Hat) they are present but 
almost nobody uses them.

---

From: Guy Harris <[email-masked]>
Date: Sat, 16 Jun 2018 15:08:28 -0700

> It doesn't. They're the same thing. At least, that's the intent.

OK, sorry, I misunderstood what you meant by "this behavior" in "this behavior is certainly not universal: it's not in the reference implementation, and it's not in macOS or Solaris." - presumably you were referring to putting the with-leap-seconds files in "right" and without-leap-seconds files into "posix", not the origins used for transition time and leap second time values.

> No, the "right" time() has the same origin as the POSIX time(). The "posix" and "right" clocks agree for all timestamps before the first leap second in 1972.

So we should perhaps have a specification of TZif files that more precisely indicates how the transition times and leap second times are represented.  Presumably for non-leap seconds files, they're represented as POSIX times and for leap seconds files they're represented as TAI seconds that have elapsed since January 1, 1970, 00:00:00 UTC.  The tzfile man page just says "as returned by time(3)", which is fine for a UN*X man page but not something I'd prefer in a specification independent of POSIX, and which also wouldn't work if the representation is different for leap seconds files.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jun 2018 15:32:49 -0700

> including leap seconds is the way to go, if we determine that its

Will anyone stand up and say that there is such a need?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jun 2018 15:38:09 -0700

On 16.06.18 15:08, Guy Harris wrote:
> So we should perhaps have a specification of TZif files that more
> precisely indicates how the transition times and leap second times are
> represented.

As Ken pointed out, we do seem to be mixing our data.  TZ information is
used as an input GMT to produce as an output localtime.  leap seconds
modify UTC.  Is there ever a case where leap seconds are not officially
observed?  Do we get ourselves into a situation where we can't tell the
difference between "we don't observe leap seconds" and "this file
assumes leap seconds have been applied"?

Eliot

---

From: Guy Harris <[email-masked]>
Date: Sat, 16 Jun 2018 15:39:31 -0700

> So we should perhaps have a specification of TZif files that more precisely indicates how the transition times and leap second times are represented.  Presumably for non-leap seconds files, they're…

The current TZif I-D says

transition times:  A series of four- or eight-octet UNIX time values
      sorted in strictly ascending order.  Each value is used as a
      transition time at which the rules for computing local time may
      change.  The number of time values is specified by the 'timecnt'
      field in the header.  Each time value SHOULD be at least -2**59.
      (-2**59 is the greatest negated power of 2 that predates the Big
      Bang, and avoiding earlier timestamps works around known TZif
      reader bugs relating to outlandlishly negative timestamps.)

and

  leap second records:  A series of eight- or twelve-octet records
      specifying the corrections that need to be applied to UTC in order
      to determine TAI.  The records are sorted by the occurrence time
      in strictly ascending order.  The number of records is specified
      by the 'leapcnt' field in the header.  If no records are present,
      or if a timestamp occurs before the occurrence time in the first
      record, the value of TAI - UTC - 10 is zero, and this zero value
      applies proleptically even to timestamps before the introduction
      of TAI or UTC.  Each record has one of the following structures:

      32-bit Data Block:

      +---------------+---------------+
      |  occur (4)    |  corr (4)     |
      +---------------+---------------+

      64-bit Data Block:

      +---------------+---------------+---------------+
      |  occur (8)                    |  corr (4)     |
      +---------------+---------------+---------------+

      occur(rence):  A four- or eight-octet UNIX time value specifying
         the time at which a leap second correction occurs.  The first
         value, if present, MUST be nonnegative, and each later value
         MUST be at least 2419199 greater than the previous value.
         (This is 28 days' worth of seconds, minus a potential negative
         leap second.)

      corr(ection):  A four-octet signed integer specifying the value of
         TAI - UTC - 10 on or after the occurrence.  The correction
         value in the first leap second record, if present, MUST be
         either one (1) or minus one (-1).  The correction values in
         adjacent leap second records MUST differ by exactly one (1).
         For timestamps that occur before the occurrence time in the
         first leap second record (or for all timestamps if there are no
         leap second records), the value of TAI - UTC - 10 is zero, and
         this zero value applies even to timestamps before the
         introduction of TAI or UTC.  (The expression "TAI - UTC - 10"
         comes from the fact that TAI - UTC was defined to be 10 just
         prior to the first leap second in 1972, so clocks with leap
         seconds that use the UNIX Time origin of 1970 have a zero
         offset relative to UTC before the first leap second.)

I might say "a four- or eight-octet time value specified as POSIX Seconds Since the Epoch", or something such as that, rather than "... UNIX time value", and include the most recent POSIX specification as a reference.

If files *with* leap second information specify them, instead, as TAI seconds that have elapsed since the Epoch, I would also note this difference for transition times; presumably leap second occurrence times are always in TAI seconds that have elapsed since the Epoch.

---

From: Guy Harris <[email-masked]>
Date: Sat, 16 Jun 2018 15:56:13 -0700

On Jun 16, 2018, at 3:38 PM, Eliot Lear <lear=[email-masked]> wrote:

> used as an input GMT to produce as an output localtime.

TZ information is usually used to convert an input value, represented as a POSIX 
"seconds since the Epoch", to local date/time year/month/day/local hours-minutes-seconds, with the time not following the UTC convention of going from 23:59:59 to 23:59:60 to 00:00:00 the next day when a leap second is inserted (so that the local time never has a seconds value greater than 59), and going from 23:58:58 to 00:00:00 the next day when a leap second is removed, or whatever the UTC convention is in that case.

zic can, however, also be used to generate TZ information that would be used to convert an input value, represented as a count of TAI seconds that have elapsed since the Epoch to year/month/day/UTC hours-minutes-seconds, or to local date/time year/month/day/local hours-minutes-seconds, expressed by a clock that *does* follow the UTC conventions.

TZ information without leap second information would be used for the first purpose.  TZ information with leap second information would be used for the second purpose.

> leap seconds modify UTC.

...and local times derived from UTC, unless the law governing local time says "*our* clocks always go from 23:59:59 to 00:00:00 the next day".

> Is there ever a case where leap seconds are not officially
> observed?

As in the law governing local time says "our* clocks always go from 23:59:59 to 00:00:00 the next day"?

> Do we get ourselves into a situation where we can't tell the

"We" meaning "the locale where the TZ information is being used"?

And "this file" meaning "a file containing times to be converted with the TZ information", "a file containing the result of converting times with the TZ information", or "a TZ information file"?

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 16:09:02 -0700

Ken Murchison wrote:
> This whole discussion brings me to a question I've had for a while, which is why 
> are the leap seconds, which I assume are universal, stuffed into every TZif 
> file?  And twice?  Why aren't they kept in a separate file, or even as a 
> separate "time zone"?

I wasn't part of that decision, but I can imagine some of the thought processes. 
Having two files (and a separate "time zone" means two files) is more 
error-prone in setup, and requires more system calls and system overhead, than 
having one file. There are two copies of the leap seconds for the same reason 
there are two copies of localtime transitions: at first there was just one copy 
with 32-bit transitions, and when the need for 64-bit time_t was realized, we 
couldn't omit or change the format of the 32-bit copy (since 32-bit clients were 
relying on it), and we couldn't limit the leap second transition times to 32 
bits (because there will probably be leap seconds after 2038). Ergo, a 64-bit copy.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jun 2018 16:36:44 -0700

On 16.06.18 15:56, Guy Harris wrote:
>
>> leap seconds modify UTC.
> ....and local times derived from UTC, unless the law governing local time says "*our* clocks always go from 23:59:59 to 00:00:00 the next day".

Only indirectly.  UTC=TAI+Sigma(leapseconds) (both positive and assuming
we would ever remove a second), right?

> As in the law governing local time says "our* clocks always go from 23:59:59 to 00:00:00 the next day"?

As in "our clocks use TAI +/- some offset".

> "We" meaning "the locale where the TZ information is being used"?

We as those developing this system?

> And "this file" meaning "a file containing times to be converted with the TZ information", "a file containing the result of converting times with the TZ information", or "a TZ information file"?

"A TZ information file".

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 17:13:18 -0700

> I might say "a four- or eight-octet time value specified as POSIX Seconds Since the Epoch", or something such as that, rather than "... UNIX time value", and include the most recent POSIX specifica…

The draft spec is already doing this in a different and more general way. "UNIX 
time" is defined to be equivalent to POSIX seconds since the Epoch for 
timestamps after 1970, and to be (negative) UT seconds before the Epoch for 
timestamps before 1970. This definition of UNIX time is designed not only to 
give the interpretation you're suggesting, but also to define timestamps before 
the Epoch (which POSIX does not).

> If files *with* leap second information specify them, instead, as TAI seconds that have elapsed since the Epoch, I would also note this difference for transition times; presumably leap second occur…

Timestamps in TZif files always use UNIX time, even in files with leap second 
support and even in their leap-second tables. The draft spec says this. If it 
isn't clear enough, what wording change could we use to make it clearer?

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 17:23:50 -0700

> ...and local times derived from UTC, unless the law governing local time says "*our*  clocks always go from 23:59:59 to 00:00:00 the next day".

Although zic and TZif support such a law (as I vaguely recall, there was some 
discussion long ago about whether leap seconds should be 23:59:60 local time or 
23:59:60 UTC), I don't know of any such law. It seems to be universal practice 
to observe the leap second at the same time around the world, so that leap 
seconds do not affect UTC offsets. For example, the most recent leap second was 
2016-12-31 23:59:60 UTC and 2016-12-31 15:59:60 PST (-0800) in Los Angeles.

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 17:40:08 -0700

> assumes leap seconds have been applied"?

Well, POSIX says that leap seconds don't exist, so there's that. :-)

As far as I know there's never been a case where a jurisdiction has decided to 
ignore leap seconds and to go out of step with the rest of the world. I doubt 
whether a jurisdiction would do that in the future, either. The last time 
somebody tried to pull a stunt that crazy was around 1949 when Beijing tried to 
switch from +08 to apparent solar time. It didn't work; even Mao at the height 
of his powers couldn't pull that off.

In practice there is no difference between "This TZif file assumes POSIX time, 
which ignores leap seconds" and "This file has leapcnt == 0".

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jun 2018 17:42:19 -0700

On 16.06.18 17:40, Paul Eggert wrote:
>
> In practice there is no difference between "This TZif file assumes
> POSIX time, which ignores leap seconds" and "This file has leapcnt == 0".

In this case, I am failing to see why we need any additional media
types.  What information is derived from an additional media type that
cannot be learned from the file itself?

Eliot

---

From: Ned Freed <[email-masked]>
Date: Sat, 16 Jun 2018 17:30:57 -0700 (PDT)

> it is darn sure close enough.

I agree 100%. Versioning can of course be done with a media type parameter, but
this has not proved to be terribly benefical for other types, mostly because
media objects exist independent of their parameter settings.

Generally speaking the only cases where this has worked well has been when the
parameter is used specific protocol labeling or negotiation scenarios.

> new media-type be procured.

If it's not compatible it really needs to be a different type. There's plenty
of stuff out there that ignores parameters completely.

>  Here some amount of prognostication is
> required.  My argument: media-types are cheap.

Exactly. THere's no need to conserve them.

>� On the off chance that

> I'm not convinced it is required.

This seems logical to me, but this is now getting away from both my
experience and expertise.

				Ned

---

From: Paul Eggert <[email-masked]>
Date: Sat, 16 Jun 2018 17:58:50 -0700

> cannot be learned from the file itself?

Nothing, if you already have the TZif file. As I understand it, this issue 
mostly came up because of the case where a client is asking the server for the 
TZif file, and wants to tell the server "I want the variant with leap second 
support" or (more likely) "I want the variant without leap second support", and 
I guess the proposal was to use the media type to distinguish these two 
requests, as there should be a standard way to distinguish between the two 
requests. Not being an expert in media types, I don't know whether the proposal 
was a good one. There are other ways to distinguish, e.g., a client could prefix 
"right/" to the name of the object requested, if it wants leap second support.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jun 2018 22:48:00 -0700

Paul,

I see we would do it with a media type as opposed to using the
leapsecond file, because to do otherwise would require not only that the
client retrieve the leapsecond file and then parse it along with a tzif
file, which would of course defeat the whole purpose of this effort. 
Before we actually go this route, I just want to know that someone would
actually test the functionality with a new media type.  Also, I think we
are entering treacherous waters: I don't want us in a position where we
require that implementations NOT have leap second information in their
files if not requested.

Eliot

On 16.06.18 17:58, Paul Eggert wrote:
> Nothing, if you already have the TZif file. As I understand it, this
> issue mostly came up because of the case where a client is asking the
> server for the TZif file, and wants to tell the server "I want the
> variant with leap second support" or (more likely) "I want the variant
> without leap second support", and I guess the proposal was to use the
> media type to distinguish these two requests, as there should be a
> standard way to distinguish between the two requests. Not being an
> expert in media types, I don't know whether the proposal was a good
> one. There are other ways to distinguish, e.g., a client could prefix

---

From: Guy Harris <[email-masked]>
Date: Sat, 16 Jun 2018 23:32:31 -0700

On Jun 16, 2018, at 10:48 PM, Eliot Lear <[email-masked]> wrote:

> file,

I.e., without a media type in the request for a TZif file, specifying whether a with-leapsecond-information or without-leapsecond-information file is desired,  the server would have to serve the same information - either a TZif file with leap second information, or a TZif file with leap second information and a separate file containing the leap second information - to all clients, with the client either inserting or removing the leap second information as necessary?

> which would of course defeat the whole purpose of this effort. 

Require that they not have leap second information in the files that they deliver to clients when a client asks for something without leap second information, or require that they have both files with leap second information and files without leap second information stored on the server for delivery to clients?

If we allow a server to deliver a file with leap second information to a client who asks for a file without leap second information, we might as well have a server that *can* deliver files with leap second information *always* deliver files with leap second information and let the client sort it out by stripping out the leap second information if necessary (for the benefit of, for example, code that always takes leap second information into account if it's present in the TZif file, and that can be handed a POSIX time and expected to generate localtime for it).

If we don't want to require that they have both types of information stored on the server, the *server* could strip the leap second information if asked for a file without leap second information.

---

From: Guy Harris <[email-masked]>
Date: Sun, 17 Jun 2018 00:00:54 -0700

> we would ever remove a second), right?

So presumably both "UTC" and "TAI" correspond here to date/hour/minute/second labels, not to counts of seconds that have elapsed since some epoch.

In that case, converting a time represented as TAI seconds that have elapsed since the Epoch to a local time represented as a date/hour/minute/second label could be done by converting that time to a UTC label and then converting that UTC label to a local time label; the first operation involves leap seconds.

The first of those is the place where "TZ information is used as an input GMT to produce as an output localtime", and the second of those is the place where "leap seconds modify UTC", but I'm not seeing why there's a problem of "mixing our data" here, as an operation that's done with a localtime() call involves both operations.  There's no *inherent* reason why a single file needs to contain both time zone and leap second information, but there's no *inherent* reason I see why they *shouldn't* contain that information, either.  As Paul noted, "Having two files (and a separate "time zone" means two files) is more error-prone in setup, and requires more system calls and system overhead, than having one file."; the *source* files for zic have separate files for time zone information and leap second information, but zic produces files that combine them.

> As in "our clocks use TAI +/- some offset".

Which would probably mean "our clocks show times as the appropriate hour/minute/second label (possibly with the date) for some TAI +/- some offset time"; presumably TAI date/hour/minute/second labels always go from 23:59:59 to 00:00:00 the next day.

> We as those developing this system?

So that applies to both the "we" in "we can't tell the difference between..." and the "we" in "we don't observe leap seconds"?

Or is the "we" in the latter case the locale to which the TZ information corresponds?

>> And "this file" meaning "a file containing times to be converted with the TZ information", "a file containing the result of converting times with the TZ information", or "a TZ information file"?

So how does a TZ information file assume, or not assume, that leap seconds have been applied?  The transition times and leap second times are all expressed as "UNIX time" as defined by the draft, so to interpret them we don't need to assume whether leap seconds have, or have not, been applied; what part of the file would depend on whether leap seconds have been applied?

Or did you mean "we can't tell the difference between "the locale to which this file applies doesn't observe leap seconds" and "this file doesn't happen to contain leap second information, even though the locale might happen to observe leap seconds""?

---

From: Lester Caine <[email-masked]>
Date: Sun, 17 Jun 2018 09:40:30 +0100

On 17/06/18 06:48, Eliot Lear wrote:
> Also, I think we

Actually I find all this simply a mess. Leap seconds are not necessary 
to define timezone transitions and can be managed locally if required. 
REMOVE all the 32/64 bit mess and simply provide a single clean set of 
data which the local applications can adjust to meat their needs.

How does all this UNIX based stuff fit in with using this with Windows 
computers? While that area is getting hit by the lack of mobile devices 
that actually use Windows ( and to be honest I don't run it on 
production desktops ) a large percentage of systems do rely on it. 
Provide a standard that can be used universally rather than one that is 
restricted to a sub set of machinery?

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 03:20:47 -0700

> isn't clear enough, what wording change could we use to make it clearer?

Oops. I double-checked this by looking at the binary data, and I got it 
completely backwards. So you were right that the draft spec is wrong about 
whether TZif timestamps count leap seconds. Sorry about that. Proposed patch 
attached.
--- draft-murchison-tzdist-tzif-06.xml	2018-06-17 03:09:24.540438847 -0700
+++ draft-murchison-tzdist-tzif-06-1.xml	2018-06-17 03:17:38.834328820 -0700
@@ -193,6 +193,13 @@
	          since the POSIX Epoch (1970-01-01 00:00:00 UTC) not counting
	          leap seconds.  As an extension to POSIX, negative values
	          represent times before the POSIX Epoch, using UT.
+		  As another extension to POSIX, if 'leapcnt' is nonzero
+		  the count of seconds includes previous leap seconds
+		  present in the leap second records (see below).
+		  For example, if the first leap second record is
+		  1972-06-30 23:59:60 UTC,
+		  the UNIX time for 1972-07-01 00:00:00 UTC is 78796801,
+		  one greater than it would be with a zero 'leapcnt'.
	        </t>
	        <t hangText="Wall Time:">
	          The time as shown on a clock set according to a location's
@@ -549,6 +556,15 @@
			  second.)
	                </t>
	              </list>
+		      Like the UNIX time values in transitions, the UNIX time
+		      values in leap second records include previously
+		      recorded leap seconds.
+		      For example, if the first leap second record is
+		      1972-06-30 23:59:60 UTC, its 'occur' is 78796800 and its
+		      'corr' is 1, and if the second leap second record is
+		      1972-12-31 23:59:60 UTC, its 'occur' is 94694401 and its
+		      'corr' is 2; the second 'occur' value counts the first
+		      leap second.
		    </t>
		    <t hangText="standard/wall indicators:">
	              A series of one-octet values indicating whether

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 03:34:59 -0700

Lester Caine wrote:
> Leap seconds are not necessary to define timezone transitions and can be managed 
> locally if required. REMOVE all the 32/64 bit mess and simply provide a single 
> clean set of data which the local applications can adjust to meat their needs.

That would be a major redesign of TZif. The goal of this draft is to document 
what we have, not to design something new. We can design something new later, if 
needed.

> computers?

A MS-Windows-based application can read TZif data just like a POSIX-based 
application can. This is already being done in applications from Microsoft and 
from other sources. See, for example:

https://referencesource.microsoft.com/mscorlib/system/timezoneinfo.cs.html

https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/localtime.cc;h=2d10508d1cf241a406d79164cfd5434548670dc6;hb=HEAD

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 04:07:00 -0700

> I.e., without a media type in the request for a TZif file, specifying whether a with-leapsecond-information or without-leapsecond-information file is desired,  the server would have to serve the sa…

Technically that can be done, because a TZif file with leap seconds contains all 
the information necessary to derive the corresponding TZif file without leap 
seconds, and it should not be hard to write a converter from the former format 
to the latter. However, I don't know of any program right now that does that 
conversion, and now is not the time to be requiring this sort of conversion in 
clients. So if we want to support leap seconds at all, there needs to be some 
way for a client to tell a server "I want leap seconds" vs "I don't want leap 
seconds". This could be via an alternate TCP port, or via special URLs, or via a 
media type.

As Eliot noted, having a separate media type doesn't feel right, since the TZif 
format has space for leap seconds. So perhaps the TZif spec should merely give 
advice that this issue needs to be resolved via URL or port number or whatever, 
and that the issue is not resolved by the TZif spec per se. The attached patch 
contains advice of that form. I realize that this is a punt, but I'm not sure 
what else to do.

> the *server* could strip the leap second information if asked for a file without leap second information.

That would work better than having the clients strip the leap second info. 
Clients typically want data without leap seconds, and low-end clients shouldn't 
have to strip out leap second information themselves.

In practice I expect servers that want to support leap seconds will precompute 
both the TZif files with leap seconds, and the files without them, and won't 
generate the latter on the fly. This is more convenient given the current state 
of zic (which generates two files) and the lack of conversion software, and it'd 
likely perform better even if the conversion software got written.
--- draft-murchison-tzdist-tzif-06-1.xml	2018-06-17 03:50:40.195199739 -0700
+++ draft-murchison-tzdist-tzif-06-2.xml	2018-06-17 04:01:00.461958256 -0700
@@ -112,13 +112,23 @@
	      used by calendaring and scheduling systems.
	      </t>
	
-	      <t>This document defines the Time Zone Information Format.  It
+	      <t>This document defines the Time Zone Information Format (TZif).  It
	      is a binary format used by most UNIX systems to calculate local
	      time.  There is a wide variety of interoperable <xref
	      target="tz-link">software</xref> capable of generating and
	      reading files in this format.
	      </t>
	
+	      <t>Although TZif provides for optional leap second adjustments,
+	      clients often prefer TZif data without leap seconds, because
+	      omitting leap seconds from the data simplifies processing on the
+	      client.
+	      This document does not specify how a client can request that a
+	      server should provide TZif data with (or without) leap seconds;
+	      such a request could be via a different URI, or via a different
+	      port, or via some other means.
+	      </t>
+	
	      <t>This specification does not define the source of the time zone
	      data or leap second information.
	      One such source is the IANA-hosted time zone database <xref

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 08:17:14 -0400

On 06/17/2018 06:20 AM, Paul Eggert wrote:
> Paul Eggert wrote:
>
>> Timestamps in TZif files always use UNIX time, even in files with 
>> leap second support and even in their leap-second tables. The draft 
>> spec says this. If it isn't clear enough, what wording change could 
>> we use to make it clearer?
>
> Oops. I double-checked this by looking at the binary data, and I got 
> it completely backwards. So you were right that the draft spec is 
> wrong about whether TZif timestamps count leap seconds. Sorry about 
> that. Proposed patch attached.

Does this indicate that the original text in the draft was correct, and 
now we are correcting the original "fix"?  The original text was crafted 
from reading tzfile(5).

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 08:48:40 -0400

On 06/17/2018 07:07 AM, Paul Eggert wrote:
>> I.e., without a media type in the request for a TZif file, specifying 
>> whether a with-leapsecond-information or 
>> without-leapsecond-information file is desired,  the server would 
>> have to serve the same information - either a TZif file with leap 
>> second information, or a TZif file with leap second information and a 
>> separate file containing the leap second information - to all 
>> clients, with the client either inserting or removing the leap second 
>> information as necessary?
>
> Technically that can be done, because a TZif file with leap seconds 
> contains all the information necessary to derive the corresponding 
> TZif file without leap seconds, and it should not be hard to write a 
> converter from the former format to the latter. However, I don't know 
> of any program right now that does that conversion, and now is not the 
> time to be requiring this sort of conversion in clients. So if we want 
> to support leap seconds at all, there needs to be some way for a 
> client to tell a server "I want leap seconds" vs "I don't want leap 
> seconds". This could be via an alternate TCP port, or via special 
> URLs, or via a media type.
>
> As Eliot noted, having a separate media type doesn't feel right, since 
> the TZif format has space for leap seconds. So perhaps the TZif spec 
> should merely give advice that this issue needs to be resolved via URL 
> or port number or whatever, and that the issue is not resolved by the 
> TZif spec per se. The attached patch contains advice of that form. I 
> realize that this is a punt, but I'm not sure what else to do.
>
> That would work better than having the clients strip the leap second 
> info. Clients typically want data without leap seconds, and low-end 
> clients shouldn't have to strip out leap second information themselves.
>
> In practice I expect servers that want to support leap seconds will 
> precompute both the TZif files with leap seconds, and the files 
> without them, and won't generate the latter on the fly. This is more 
> convenient given the current state of zic (which generates two files) 
> and the lack of conversion software, and it'd likely perform better 
> even if the conversion software got written.

I'm at the point where I think we can treat leap seconds in TZif over 
TZDIST as a non-issue.  We use just one, unparameterized MIME type as 
currently defined.

 From a server perspective, it can choose to [not] include leap seconds 
in the TZif files.  From a client perspective, if it wants leap seconds, 
it can look in the TZif files to see if they are present.  If not 
present, it can check to see if the TZDIST server supports the 
'leapseconds' action and fetch them that way. Otherwise, the client 
needs to look elsewhere for the data.

Does this make sense and is it viable?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Jun 2018 08:42:26 -0700

> realize that this is a punt, but I'm not sure what else to do.

No I am ok with a media type if we need it, and I would prefer that to
using a different port or protocol extension.  I am just trying to
understand the justification.

Eliot

---

From: Guy Harris <[email-masked]>
Date: Sun, 17 Jun 2018 09:29:50 -0700

On Jun 17, 2018, at 4:07 AM, Paul Eggert <[email-masked]> wrote:

> Technically that can be done, because a TZif file with leap seconds contains all the information necessary to derive the corresponding TZif file without leap seconds, and it should not be hard to write a converter from the former format to the latter.

BTW, it sounds, from your recent message with the patch to the draft, as if you can't just strip the leap second information to make a "no leap second" TZIf file from a "with leap seconds" TZif file, you also have to POSIX-ize the transition times by subtracting past leap seconds.

> However, I don't know of any program right now that does that conversion, and now is not the time to be requiring this sort of conversion in clients. So if we want to support leap seconds at all, there needs to be some way for a client to tell a server "I want leap seconds" vs "I don't want leap seconds". This could be via an alternate TCP port, or via special URLs, or via a media type.
> 
> As Eliot noted, having a separate media type doesn't feel right, since the TZif format has space for leap seconds. So perhaps the TZif spec should merely give advice that this issue needs to be resolved via URL or port number or whatever, and that the issue is not resolved by the TZif spec per se. The attached patch contains advice of that form. I realize that this is a punt, but I'm not sure what else to do.

I might vote for "via URL", e.g. with a "query" part such as "?leapseconds={yes, no}".

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Jun 2018 09:32:04 -0700

> I might vote for "via URL", e.g. with a "query" part such as "?leapseconds={yes, no}".

That doesn't jibe with the existing tzdist model.  In this sense, Ken is
right that if we need this, we should use a media type.

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 10:58:25 -0700

Guy Harris wrote:

> it sounds, from your recent message with the patch to the draft, as if you can't just strip the leap second information to make a "no leap second" TZIf file from a "with leap seconds" TZif file, you also have to POSIX-ize the transition times by subtracting past leap seconds.

Yes, that's right. Although it shouldn't be hard to do that conversion, in 
practice nobody does it, and I don't think the TZif spec should imply that 
clients must start doing it.

> I might vote for "via URL", e.g. with a "query" part such as "?leapseconds={yes, no}".

That should work too.

In practice we will need some sort of mechanism if we want tzdist + TZif to 
support leap seconds. The vast majority of clients will want data without leap 
seconds, so that will be the default. If there's no recognized way to specify "I 
want leap seconds" then by and large leap seconds will not work.

As I understand it, Eliot is saying that it's OK to use a media type if needed, 
and Ken is saying that it's OK if servers send whatever form they like as the 
default (no doubt without leap seconds, since that's by far the most popular), 
with some sort of fallback URL that specifies that one wants the leap second 
form. Either approach will work and I don't much care myself. Whatever we 
decide, the spec should record that decision so that it gives some guidance in 
this area.

The wording I proposed 
<https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00130.html> takes a 
vague use-a-different-URL approach mostly because I'm no expert in tzdist and 
media types. No doubt it can be improved, and suggesting a specific query (as in 
your comment above) would encourage interoperability. I'm getting the feeling 
that our tzdist experts would rather go the media-type route, and in that case 
Eliot is saying that he'd like a test of functionality before having the spec 
recommend media types, which makes sense to me but I'm not the guy to do that test.

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 14:27:15 -0400

On 06/17/2018 01:48 AM, Eliot Lear wrote:
> actually test the functionality with a new media type.

FWIW, my server implementation already uses application/tzif and 
application/tzif+leap.  If the Accept request header field specifies the 
latter, the returned TZif files will contain leap second records.  
Otherwise, they will have leapcnt=0.

Whether the latter MIME type is needed is still up for debate.  This 
initial goal of specifying TZif with TZDIST would be for a system to 
that uses TZif as its time zone data, to update time that data via 
TZDIST rather than via OS updates.  I don't know if most systems use the 
TZif files with leapseconds.

But as I said previously, any client that actually wants the leap second 
data can fetch it using the 'leapsecond' TZDIST action and insert that 
data into TZif files itself if required.  Because TZif doesn't use file 
offsets, inserting that data should be pretty straightforward.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 11:35:16 -0700

Ken Murchison wrote:
> Does this indicate that the original text in the draft was correct, and now we 
> are correcting the original "fix"?  The original text was crafted from reading 
> tzfile(5).

Yes and no. Yes, in that I screwed up and inserted text clearly stating that 
TZif timestamps use POSIX time (i.e., they ignore leap seconds). No, in the 
sense that draft-murchison-tzdist-tzif-00 also said that TZif timestamps use 
POSIX time (though it did so in a vaguer way).

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 14:37:28 -0400

On 06/17/2018 02:35 PM, Paul Eggert wrote:
> Ken Murchison wrote:
>> Does this indicate that the original text in the draft was correct, 
>> and now we are correcting the original "fix"?  The original text was 
>> crafted from reading tzfile(5).
>
> Yes and no. Yes, in that I screwed up and inserted text clearly 
> stating that TZif timestamps use POSIX time (i.e., they ignore leap 
> seconds). No, in the sense that draft-murchison-tzdist-tzif-00 also 
> said that TZif timestamps use POSIX time (though it did so in a vaguer 
> way).

Does that mean that tzfile(5) is also incorrect?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Guy Harris <[email-masked]>
Date: Sun, 17 Jun 2018 11:49:24 -0700

On Jun 17, 2018, at 11:27 AM, Ken Murchison <[email-masked]> wrote:

> But as I said previously, any client that actually wants the leap second data can fetch it using the 'leapsecond' TZDIST action and insert that data into TZif files itself if required.  Because TZif doesn't use file offsets, inserting that data should be pretty straightforward.

Note that "inserting that data" includes "adjusting all the transition times, as necessary, so that they're "TAI seconds that have elapsed since the Epoch", rather than POSIX "seconds since the Epoch", by adding leap seconds.

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 11:51:50 -0700

Ken Murchison wrote:

> application/tzif+leap.  If the Accept request header field specifies the latter, 
> the returned TZif files will contain leap second records. Otherwise, they will 
> have leapcnt=0.

Ah, OK, in that case, haven't you already satisfied Eliot's desire "to know that 
someone would actually test the functionality with a new media type"? And if you 
haven't satisfied it, what more would need to be done to satisfy it?

> I don't know if most systems use the TZif files with leapseconds.

I think most GNU/Linux distributions have both kinds of TZif files and most 
other systems have just the non-leapseconds files. On the GNU/Linux systems, 
almost nobody actually uses the leapseconds files; that being said, software 
updates invariably affect the leapseconds files at the same time they affect the 
non-leapseconds files.
> any client that actually wants the leap second data 
> can fetch it using the 'leapsecond' TZDIST action and insert that data into TZif 
> files itself if required.  Because TZif doesn't use file offsets, inserting that 
> data should be pretty straightforward.

All true, except nobody does that now and the software would have to be written 
and this would slow down tzdist+TZif takeup among GNU/Linux clients that want to 
use tzdist+TZif to update their timezone files instead of using OS upgrades to 
do that (I assume this is a significant goal of tzdist+TZif). Plus, there are 
two plausible ways to insert leap seconds into TZif files (stationary vs 
rolling) and quite possibly some client will do it the "wrong" way.

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 11:58:26 -0700

> Does that mean that tzfile(5) is also incorrect?

No, because tzfile(5) doesn't say that time() returns POSIX time. That is, it's 
silent on what time() returns and it assumes that one uses a TZif file with leap 
seconds if and only if time() counts leap seconds. This is not incorrect; it's 
just vague.

At some point I was hoping to clear tzfile(5) up by incorporating clarifying 
text from the TZif draft into tzfile(5) once things have settled down. (Or would 
that violate IETF copyright rules? If so, I'd have to rewrite the relevant parts 
from scratch. Let's hope it doesn't come to that!)

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 14:59:25 -0400

> Note that "inserting that data" includes "adjusting all the transition times, as necessary, so that they're "TAI seconds that have elapsed since the Epoch", rather than POSIX "seconds since the Epo…

I don't believe so.  AFAIK, the transitions for time zone changes and 
leap second changes are mutually exclusive.  In fact, the code in my 
TZdist server that generates TZif uses the same code for time zone 
transitions whether its adding leap second records or not.  And I have 
done binary comparisons of these files against zic output.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 15:08:08 -0400

On 06/17/2018 02:51 PM, Paul Eggert wrote:
>> application/tzif+leap.  If the Accept request header field specifies 
>> the latter, the returned TZif files will contain leap second records. 
> Ah, OK, in that case, haven't you already satisfied Eliot's desire "to 
> know that someone would actually test the functionality with a new 
> media type"? And if you haven't satisfied it, what more would need to 
> be done to satisfy it?

Nothing from my end AFAIK.  Eliot, are you looking for client support as 
well?

> I think most GNU/Linux distributions have both kinds of TZif files and 
> most other systems have just the non-leapseconds files. On the 
> GNU/Linux systems, almost nobody actually uses the leapseconds files; 
> that being said, software updates invariably affect the leapseconds 
> files at the same time they affect the non-leapseconds files.
>> any client that actually wants the leap second data can fetch it 
>> using the 'leapsecond' TZDIST action and insert that data into TZif 
>> files itself if required. Because TZif doesn't use file offsets, 
>> inserting that data should be pretty straightforward.
>
> All true, except nobody does that now and the software would have to 
> be written and this would slow down tzdist+TZif takeup among GNU/Linux 
> clients that want to use tzdist+TZif to update their timezone files 
> instead of using OS upgrades to do that (I assume this is a 
> significant goal of tzdist+TZif). Plus, there are two plausible ways 
> to insert leap seconds into TZif files (stationary vs rolling) and 
> quite possibly some client will do it the "wrong" way.

One of the things that my colleagues at CalConnect and I have discussed 
is writing an open source TZdist client which can be used to update the 
system time zone data as a proof of concept and reference implementation.

I think the bigger impediment is to get someone to run a root server 
(preferably IANA), and then get OS providers (Redhat, Ubuntu, FreeBSD, 
etc) to run secondary servers.

I hope to get my employer to stand up a demo/test TZdist server soon, 
which would include support for both TZif and the geolocate extension.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 15:10:02 -0400

On 06/17/2018 02:58 PM, Paul Eggert wrote:
> No, because tzfile(5) doesn't say that time() returns POSIX time. That 
> is, it's silent on what time() returns and it assumes that one uses a 
> TZif file with leap seconds if and only if time() counts leap seconds. 
> This is not incorrect; it's just vague.
>
> At some point I was hoping to clear tzfile(5) up by incorporating 
> clarifying text from the TZif draft into tzfile(5) once things have 
> settled down. (Or would that violate IETF copyright rules? If so, I'd 
> have to rewrite the relevant parts from scratch. Let's hope it doesn't 
> come to that!)

AFAIK, text in RFCs is in the public domain.  And given that you're a 
co-author, I'm sure you are free to borrow text from yourself.

Eliot can correct me if I'm wrong.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Sun, 17 Jun 2018 12:13:13 -0700

Ken Murchison wrote:
> AFAIK, the transitions for time zone changes and leap 
> second changes are mutually exclusive.  In fact, the code in my TZdist server 
> that generates TZif uses the same code for time zone transitions whether its 
> adding leap second records or not.  And I have done binary comparisons of these 
> files against zic output.

That's odd, because I just wrote a simple program that looks at the binary data, 
and it showed the opposite, i.e., that time zone transitions are affected by 
whether leap seconds were added. Could you please try the following? Compile and 
run the attached program on (say) the America/Los_Angeles data, both with and 
without leap seconds, like this on a Debian-based system:

gcc zd64.c
./a.out </usr/share/zoneinfo/America/Los_Angeles >Los_Angeles-noleap.txt
./a.out </usr/share/zoneinfo/right/America/Los_Angeles >Los_Angeles-leap.txt

I did that and got the attached *.txt files. Notice, for example, that 
transition 56 is at time 89197201 in the version with leap seconds, and at time 
89197200 without. This demonstrates that the TZif time zone transition 
timestamps are affected by the presence of leap seconds.

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 15:14:51 -0400

On 06/17/2018 03:13 PM, Paul Eggert wrote:
> Ken Murchison wrote:
>> AFAIK, the transitions for time zone changes and leap second changes 
>> are mutually exclusive.  In fact, the code in my TZdist server that 
>> generates TZif uses the same code for time zone transitions whether 
>> its adding leap second records or not.  And I have done binary 
>> comparisons of these files against zic output.
>
> That's odd, because I just wrote a simple program that looks at the 
> binary data, and it showed the opposite, i.e., that time zone 
> transitions are affected by whether leap seconds were added. Could you 
> please try the following? Compile and run the attached program on 
> (say) the America/Los_Angeles data, both with and without leap 
> seconds, like this on a Debian-based system:
>
> gcc zd64.c
> ./a.out </usr/share/zoneinfo/right/America/Los_Angeles 
> >Los_Angeles-leap.txt
>
> transition 56 is at time 89197201 in the version with leap seconds, 
> and at time 89197200 without. This demonstrates that the TZif time 
> zone transition timestamps are affected by the presence of leap seconds.

Will do that this week.  I will also review my code to make sure I 
wasn't talking out my ass.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Guy Harris <[email-masked]>
Date: Sun, 17 Jun 2018 12:22:01 -0700

> On Jun 17, 2018, at 11:59 AM, Ken Murchison <[email-masked]> wrote:
> 
> 
> 
> I don't believe so.

You don't believe that with-leap-seconds and without-leap-seconds TZif files use different numerical values for the transition times for a given transition?

Unless I've misread Paul Eggert's mail in which he said

> Paul Eggert wrote:
> 
>> Timestamps in TZif files always use UNIX time, even in files with leap second support and even in their leap-second tables. The draft spec says this. If it isn't clear enough, what wording change could we use to make it clearer?
> 
> Oops. I double-checked this by looking at the binary data, and I got it completely backwards. So you were right that the draft spec is wrong about whether TZif timestamps count leap seconds. Sorry about that. Proposed patch attached.

> +++ draft-murchison-tzdist-tzif-06-1.xml	2018-06-17 03:17:38.834328820 -0700

he appears to be saying that transition times in with-leap-seconds files (leapcnt nonzero) count leap seconds - i.e., they're "TAI seconds that have elapsed since the Epoch" - and transition times in without-leap-seconds files (leapcnt zero) files don't count leap seconds - i.e., they're POSIX seconds-since-the-epoch.

> AFAIK, the transitions for time zone changes and leap second changes are mutually exclusive.  In fact, the code in my TZdist server that generates TZif uses the same code for time zone transitions whether its adding leap second records or not.  And I have done binary comparisons of these files against zic output.

I have done binary comparisons of the America/Los_Angeles files produced by "zic -L leapseconds northamerica" and "zic northamerica", and there are differences other than a different value in the leapcnt field and the extra information at the end of the with-leapseconds-data file.  Are you *absolutely certain* that files produced with "zic -L leapseconds" and the same files produced without "-L leapseconds" have the same numerical values for all transition times?

---

From: Ken Murchison <[email-masked]>
Date: Sun, 17 Jun 2018 15:24:17 -0400

> I have done binary comparisons of the America/Los_Angeles files produced by "zic -L leapseconds northamerica" and "zic northamerica", and there are differences other than a different value in the l…

At this point I am NOT certain.  I may have remembered my code 
incorrectly and/or my code itself is incorrect.  I will review my code 
this week.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 09:42:59 -0400

> zone transition timestamps are affected by the presence of leap seconds.

As expected I was mistaken and my code DOES add leap seconds to the time 
zone transition times.

Running your dump program on my generated TZif files yields the same 
results as yours.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Jun 2018 06:46:41 -0700

> media type"? And if you haven't satisfied it, what more would need to

Yep.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Jun 2018 06:48:13 -0700

> Eliot

Just to be clear, my point is that I didn't want us writing spec code
that nobody has either tested or used.  If it's not needed, why add it? 
Ken's code is a big step in that direction.  Having *some* client code
to test it would be good.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Jun 2018 06:55:40 -0700

On 17.06.18 12:10, Ken Murchison wrote:
>> No, because tzfile(5) doesn't say that time() returns POSIX time.
>> That is, it's silent on what time() returns and it assumes that one
>> uses a TZif file with leap seconds if and only if time() counts leap
>> seconds. This is not incorrect; it's just vague.
>>
>> have to rewrite the relevant parts from scratch. Let's hope it
>> doesn't come to that!)
>

RFCs are not in the public domain.  That having been said, I'm confident
there won't be an issue.  A small small amount of consultation is
perhaps necessary, since I'm not an IPR expert.  Leave it with me for
the moment.

Eliot

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 09:56:06 -0400

> to test it would be good.

FWIW, these work against my server and return the desired results:

curl -H Accept:application/tzif http://localhost/tzdist/zones/Europe/Zurich
curl -H Accept:application/tzif+leap 
http://localhost/tzdist/zones/Europe/Zurich

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 12:52:30 -0400

Now that I have realized the the transition times in files that include 
leap second records actually utilize leap seconds, I think I'm 
gravitating towards having a separate or parameterized MIME type to 
indicate that the TZif includes leap seconds.  This other MIME type can 
be advertised by the TZDIST server in the capabilities if it supports 
it, and can be specified by the client in the Accept header field it 
wants leap second records.

Question for Paul, is software that wants POSIX transitions capable of 
using a TZif file with leap seconds and translating the transitions?  If 
not, then I think this adds to the argument that we need 2 separate or 
parameterized MIME types - one to indicate NO leap seconds, and the 
other to indicate leap seconds are included.

-- 

Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 14:21:47 -0400

> that. Proposed patch attached.

I understand where you're going with this, but the initial part of the 
description of UNIX time says it doesn't include leap seconds. And then 
we add text starting that it can/does based on a reference to a field 
value which isn't described until further down the document.

I think we need a better way  to discuss that transitions times and leap 
second occurrences may include previous leap seconds.  At the moment, 
I'm not sure how best to do this.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Guy Harris <[email-masked]>
Date: Mon, 18 Jun 2018 11:43:54 -0700

On Jun 18, 2018, at 11:21 AM, Ken Murchison <[email-masked]> wrote:

> I think we need a better way  to discuss that transitions times and leap second occurrences may include previous leap seconds.  At the moment, I'm not sure how best to do this.

One possibility would be to define "UNIX time" as it's defined now, and then define another time, with a different name, e.g.

	XYZZY Time:  The time represented as an integer number of seconds since the POSIX Epoch (1970-01-01 00:00:00 UTC), counting leap seconds.  Negative values represent times before the POSIX Epoch, using UT.

and then say

	transition times:  A series of four- or eight-octet UNIX time values, in files where the 'leapcnt' value is zero, or XYZZY time values, in files where the 'leapcnt' value is non-zero, sorted in strictly ascending order.  {unchanged text omitted}

and

	leap second records:  A series of eight- or twelve-octet records specifying the corrections that need to be applied to UTC in order to determine TAI.  {unchanged text omitted}.

	...

      occur(rence):  A four- or eight-octet XYZZY time value specifying the time at which a leap second correction occurs.  {unchanged text omitted}

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 14:48:26 -0400

>        occur(rence):  A four- or eight-octet XYZZY time value specifying the time at which a leap second correction occurs.  {unchanged text omitted}

I like this idea.  Now, what do we call it?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 13:53:48 -0700

> I like this idea.  Now, what do we call it? 

Let's call it "UNIX leap time", to key off the word "leap" in the media 
type. Proposed patch attached. It uses "UNIX time" only to define "UNIX 
leap time", since the two notions are equivalent when leapcnt is zero.

--- draft-murchison-tzdist-tzif-06.xml	2018-06-17 03:09:24.540438847 -0700
+++ draft-murchison-tzdist-tzif-06-1a.xml	2018-06-18 13:51:09.422698327 -0700
@@ -194,6 +194,16 @@
	          leap seconds.  As an extension to POSIX, negative values
	          represent times before the POSIX Epoch, using UT.
	        </t>
+		<t hangText="UNIX Leap Time">
+		  This is like UNIX time, except it also counts the leap seconds
+		  specified in the TZif file.
+		  For example, if the file's first leap second record is
+		  1972-06-30 23:59:60 UTC, the UNIX leap time for the timestamp
+		  1972-07-01 00:00:00 UTC is 78796801, one greater than same
+		  timestamp's UNIX time.
+		  If a TZif file specifies no leap seconds,
+		  UNIX leap time is equivalent to UNIX time.
+		</t>
	        <t hangText="Wall Time:">
	          The time as shown on a clock set according to a location's
	          law or practice.
@@ -407,7 +417,7 @@
	        <t>
		  <list style='hanging'>
		    <t hangText="transition times:">
-		      A series of four- or eight-octet UNIX time values sorted
+		      A series of four- or eight-octet UNIX leap time values sorted
	              in strictly ascending order.
	              Each value is used as a transition time at which the rules
	              for computing local time may change.
@@ -520,7 +530,7 @@
	              </list>
		      <list style='hanging'>
		        <t hangText="occur(rence):">
-	                  A four- or eight-octet UNIX time value specifying the
+	                  A four- or eight-octet UNIX leap time value specifying the
	                  time at which a leap second correction occurs.
			  The first value, if present, MUST be nonnegative,
			  and each later value MUST be at least 2419199
@@ -549,6 +559,14 @@
			  second.)
	                </t>
	              </list>
+		      Like transitions, the UNIX leap times in leap second
+		      records count previously recorded leap seconds.
+		      For example, if the first leap second record is
+		      1972-06-30 23:59:60 UTC, its 'occur' is 78796800 and its
+		      'corr' is 1, and if the second leap second record is
+		      1972-12-31 23:59:60 UTC, its 'occur' is 94694401 and its
+		      'corr' is 2; the second 'occur' value counts the first
+		      leap second.
		    </t>
		    <t hangText="standard/wall indicators:">
	              A series of one-octet values indicating whether

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 14:10:03 -0700

On 06/18/2018 09:52 AM, Ken Murchison wrote:
> is software that wants POSIX transitions capable of using a TZif file 
> with leap seconds and translating the transitions?

Typically yes; at least it's true for GNU/Linux and the BSDs. However, 
it could well be that some clients mishandle leap seconds, as they're 
not used as often. Also, even if the client OS supports leap seconds, 
the user might not want leap seconds.

---

From: Guy Harris <[email-masked]>
Date: Mon, 18 Jun 2018 14:16:20 -0700

On Jun 18, 2018, at 2:10 PM, Paul Eggert <[email-masked]> wrote:

>> is software that wants POSIX transitions capable of using a TZif file with leap seconds and translating the transitions?
> 
> Typically yes; at least it's true for GNU/Linux and the BSDs.

I.e, both the GNU libc code, and the reference-implementation-based(?) libc code in various BSDs, could be handed a right/ file and would properly translate the result of a POSIX-compliant time()?

Or was something else meant by "software that wants POSIX transitions" and "capable of using a TZif file with leap seconds"?

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 14:18:34 -0700

> I.e, both the GNU libc code, and the reference-implementation-based(?) libc code in various BSDs, could be handed a right/ file and would properly translate the result of a POSIX-compliant time()?

No, I meant that the code could be handed a right/ file and would 
properly translate the result of a time() that acted like POSIX except 
that time() counted leap seconds.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 17:23:42 -0400

On 06/18/2018 05:18 PM, Paul Eggert wrote:
>>>> is software that wants POSIX transitions capable of using a TZif 
>>>> file with leap seconds and translating the transitions?
>> I.e, both the GNU libc code, and the 
>> reference-implementation-based(?) libc code in various BSDs, could be 
>> handed a right/ file and would properly translate the result of a 
>> POSIX-compliant time()?
>

Maybe I'm getting confused, but my question is can existing software, 
GLibc or otherwise, take a right/ file and and spit out POSIX time?  In 
other words, is it smart enough to subtract leap seconds from time zone 
transitions?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 14:30:32 -0700

On 06/18/2018 02:23 PM, Ken Murchison wrote:
> GLibc or otherwise, take a right/ file and and spit out POSIX time?  
> In other words, is it smart enough to subtract leap seconds from time 
> zone transitions?

No. With existing software, either time() returns UNIX time and you use 
a TZif file without leap seconds, or time() returns UNIX leap time and 
you use a TZif file with leap seconds. And both alternatives are really 
the same thing: strictly speaking "UNIX leap time" is defined by the 
leap seconds recorded in the TZif file not the leap seconds published by 
the IERS, so if the TZif file says there are no leap seconds then UNIX 
leap time is equivalent to UNIX time.

---

From: Guy Harris <[email-masked]>
Date: Mon, 18 Jun 2018 14:38:23 -0700

On Jun 18, 2018, at 2:23 PM, Ken Murchison <[email-masked]> wrote:

> Maybe I'm getting confused, but my question is can existing software, GLibc or otherwise, take a right/ file and and spit out POSIX time?  In other words, is it smart enough to subtract leap seconds from time zone transitions?

POSIX time is a count of seconds, so, for the reference implementation, the routine that one might expect to spit out POSIX time would be mktime().  localtime() and gmtime() would take POSIX time as an *input*, so perhaps the question should have been "can any existing software take a right/ time and *work with* POSIX time values?"

I think the answer to that question is "no", at least for the reference implementation and, I suspect, most if not all implementations based on the reference implementation, as well as the GNU libc implementation - if you will be handing localtime() and gmtime() POSIX times, and will be handing mtkime() dates and times that you would expect to be converted to POSIX times, you would have to configure them to read posix/ files.

If you want localtime() and gmtime() to take "UNIX leap time" values, to use Paul's suggested name, as arguments, and you want mtkime() to take a date/time value and convert it to a "UNIX leap time" value, you would have to configure them to read right/ values.

---

From: Guy Harris <[email-masked]>
Date: Mon, 18 Jun 2018 14:39:17 -0700

On Jun 18, 2018, at 2:18 PM, Paul Eggert <[email-masked]> wrote:

> No, I meant that the code could be handed a right/ file and would properly translate the result of a time() that acted like POSIX except that time() counted leap seconds.

Meaning "a time() that returns UNIX leap time", to use your suggested name?

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 14:46:40 -0700

> Meaning "a time() that returns UNIX leap time", to use your suggested name?
Yes.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 17:53:24 -0400

On 06/18/2018 04:53 PM, Paul Eggert wrote:
> Let's call it "UNIX leap time", to key off the word "leap" in the 
> media type. Proposed patch attached. It uses "UNIX time" only to 
> define "UNIX leap time", since the two notions are equivalent when 
> leapcnt is zero.

Trying to make "UNIX Leap Time" more concise and more explicit.  How 
does this sound?

UNIX Leap Time:

UNIX time plus the sum of all preceding leap second corrections.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 14:55:07 -0700

> UNIX time plus the sum of all preceding leap second corrections. 

That works for me. We could make it even shorter by omitting "the sum of".

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 17:58:02 -0400

> That works for me. We could make it even shorter by omitting "the sum 

Even better.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 15:02:37 -0700

On 06/18/2018 02:38 PM, Guy Harris wrote:
> I think the answer to that question is "no", at least for the reference implementation and, I suspect, most if not all implementations based on the reference implementation

I thought so too, and wrote a previous email along those lines. But I 
forgot about time2posix and posix2time. These functions are in the 
reference implementation and in some distributions, notably the BSDs 
(but not GNU/Linux, and they weren't public in FreeBSD until a month 
ago). On a system that uses "right" time, these functions convert time_t 
values between POSIX ("UNIX time") and right ("UNIX leap time") formats. 
On a system that uses POSIX time (i.e., leapcnt = 0), UNIX time and UNIX 
leap time are identical and time2posix and posix2time are both identity 
functions.

On a system with "right" time, it's a pain to deal with POSIX timestamps 
because localtime, gmtime, etc. all use "right" timestamps. So to some 
extent the time2posix and posix2time functions are curiosities. Although 
I suppose they could be useful for programs like 'tar' that want to 
output binary timestamps in a portable (presumably POSIX) format even 
when running on a system with "right" time, they don't seem to be used 
much in practice (e.g., GNU Tar does not use them).