Re: [LEAPSECS] Time math libraries, UTC to TAI

Brooks Harris wrote: >There is a hole in the data of these tables; Rec 460 tells us the origin of >TAI is "1 January 1958" but the first TAI-UTC value listed in the tables is >in 1961 - what happened between 1958 and 1961? You've previously shown some confusion along these lines, and I think the

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

i...@bsdimp.com said: >> Could that be solved with 2 functions in the API, one for N seconds >> from now, and a second for at some future date/time specified in >> Y/M/D/H/M/S format rather than something like a time_t? > Only partially (meaning only assuming every day has exactly 86400

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Fri, Dec 30, 2016 at 10:11 PM, Rob Seaman wrote: > On Dec 29, 2016, at 1:35 PM, Warner Losh wrote: > > A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X > was launched in 2001. > > > Could have, but didn’t... > > Of course, MacOS is largely

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Fri, Dec 30, 2016 at 9:52 PM, Steve Summit wrote: > Warner Losh wrote: >> On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray wrote: >> >> One could imagine having a more complicated structure that could cope with >> >> the inherent ambiguity in future

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

Warner Losh wrote: > On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray wrote: > >> One could imagine having a more complicated structure that could cope with > >> the inherent ambiguity in future times. I can't say "schedule an event > >> exactly 1 year from now" for example

[LEAPSECS] 2016 is not tied for second longest year ever

Leap second trivia for the end of the year. 1972 was a leap year and had 2 leap seconds for a total of 31622402 SI s. 2016 is a leap year with only 1 leap second for a total of 31622401 SI s. But according to Stephenson, Morrison, Hohenkerk (2016) the year 1904 was the second longest year ever

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Fri, Dec 30, 2016 at 6:47 PM, Steve Allen wrote: > On Fri 2016-12-30T17:59:14 -0700, Warner Losh hath writ: >> if you were to transition to a TAI world, then you'd not be able to >> implement the latter for a TAI time of the UTC time at some >> Y/M/D/H/M/S past the end of the

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Fri 2016-12-30T17:59:14 -0700, Warner Losh hath writ: > if you were to transition to a TAI world, then you'd not be able to > implement the latter for a TAI time of the UTC time at some > Y/M/D/H/M/S past the end of the next six month boundary, since it is > impossible to have that knowledge.

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray wrote: > >> One could imagine having a more complicated structure that could cope with >> the inherent ambiguity in future times. I can't say "schedule an event >> exactly 1 year from now" for example without it. I need

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

> One could imagine having a more complicated structure that could cope with > the inherent ambiguity in future times. I can't say "schedule an event > exactly 1 year from now" for example without it. I need additional metadata > around to know if I want it to happen at the same time of day on

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Fri, Dec 30, 2016 at 7:28 AM, Steffen Nurpmeso wrote: > Never having done kernel programming, this doesn't sound logical > to me. You have a clock source and a conversion algorithm. That > runs every time, maybe even millions time a second? Maybe kernels > exist which

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

On Thu, Dec 29, 2016 at 9:42 PM, Rob Seaman wrote: > On Dec 29, 2016, at 1:35 PM, Warner Losh wrote: > >>> A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X >>> was launched in 2001. >> >> Could have, but didn’t... >> >> Of

Re: [LEAPSECS] The POSIX Time Rationale - in the Working Group's own words

In message <20161230204404.ga4...@ucolick.org>, Steve Allen writes: >On Fri 2016-12-30T20:20:57 +, Poul-Henning Kamp hath writ: >> >It may prove useful to know why the POSIX Working Group (WG) excluded >> >leap seconds, in their own words. >> >> POSIX didn't "exclude leap seconds",

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2016-12-30 12:56 PM, Stephen Scott wrote: NOT "unintentional" -S On 2016-12-30 11:37, Brooks Harris wrote: In SMPTE standards parlance the first sentence is normative, but the "Note" is informative. The intention of the note is to inform implementers that the intention for SMPTE

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2016-12-30 12:39 PM, Steve Allen wrote: On Fri 2016-12-30T11:37:38 -0500, Brooks Harris hath writ: There is a hole in the data of these tables; Rec 460 tells us the origin of TAI is "1 January 1958" but the first TAI-UTC value listed in the tables is in 1961 - what happened between 1958 and

Re: [LEAPSECS] The POSIX Time Rationale - in the Working Group's own words

On 2016-12-30 12:11 PM, Steve Allen wrote: On Fri 2016-12-30T10:49:19 -0500, Joseph Gwinn hath writ: It may prove useful to know why the POSIX Working Group (WG) excluded leap seconds, in their own words. A bit more insight comes from the 1986 draft POSIX and the 1988 first version of the

Re: [LEAPSECS] Time math libraries, UTC to TAI

NOT "unintentional" -S On 2016-12-30 11:37, Brooks Harris wrote: On 2016-12-28 04:16 PM, Steve Allen wrote: On Wed 2016-12-28T16:00:17 -0500, Brooks Harris hath writ: I don't think so. This is POSIX so-called "1970-01-01 00:00:00 UTC" not 1588/PTP. 1588/PTP epoch is 10s earlier. At

Re: [LEAPSECS] Time math libraries, UTC to TAI

On Fri 2016-12-30T11:37:38 -0500, Brooks Harris hath writ: > There is a hole in the data of these tables; Rec 460 tells us the > origin of TAI is "1 January 1958" but the first TAI-UTC value listed > in the tables is in 1961 - what happened between 1958 and 1961? What > does "1 January 1958" mean;

Re: [LEAPSECS] The POSIX Time Rationale - in the Working Group's own words

On Fri 2016-12-30T10:49:19 -0500, Joseph Gwinn hath writ: > It may prove useful to know why the POSIX Working Group (WG) excluded > leap seconds, in their own words. A bit more insight comes from the 1986 draft POSIX and the 1988 first version of the standard.

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2016-12-28 04:16 PM, Steve Allen wrote: On Wed 2016-12-28T16:00:17 -0500, Brooks Harris hath writ: I don't think so. This is POSIX so-called "1970-01-01 00:00:00 UTC" not 1588/PTP. 1588/PTP epoch is 10s earlier. At 1970-01-01 the difference TAI - UTC(BIH) was 8.82 SI seconds. I trust

Re: [LEAPSECS] Time math libraries, UTC to TAI

> On December 29, 2016 at 6:00 PM Steve Allen wrote, in part: > > On Thu 2016-12-29T09:26:58 -0700, Warner Losh hath writ: > > > How do you deal with acquiring knowledge of leap seconds after you've > > given out 'old' timestamps that might be affected by them? This is > >

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

Warner Losh wrote: |If there was an easy solution, it would have emerged by now. Trouble ... |support for spending boatloads of money to fix it. The problem is that |you never know if the following code has a leap second issue or not. |Let's suppose for a minute we redefined

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

Rob Seaman wrote: |The argument appears to be that POSIX is such crap that we have to \ |degrade other technologies. This may be aligned with the zeitgeist \ |of 2016, yet remains oddly unpersuasive. Having a standardized CLOCK_TAI improves the situation enormously, at