Re: [LEAPSECS] leap seconds in POSIX

On Mon 2020-01-27T21:17:54+ Tony Finch hath writ: > > The LOD effects are easier to see using the plots from the Paris > > bureau of IERS by requesting to remove the predictable tidal > > variations that basically look like noise on the second plot here. > > Do you have a link and/or

Re: [LEAPSECS] leap seconds in POSIX

Steve Allen wrote: > > The LOD effects are easier to see using the plots from the Paris > bureau of IERS by requesting to remove the predictable tidal > variations that basically look like noise on the second plot here. Do you have a link and/or instructions? I can't see how to get a chart like

Re: [LEAPSECS] leap seconds in POSIX

On Mon 2020-01-27T19:33:37+ Tony Finch hath writ: > It looks like we're in another long gap, based on the LOD chart and the > UT1-UTC prediction. The current gap is now the second longest... In the middle of last year the rotation of the earth accelerated enough that LOD went below 86400 for

Re: [LEAPSECS] leap seconds in POSIX

Steve Summit wrote: > * The leap second drought of 1999-2006 rather nastily coincided > with a gradual change in the computing industry from "nobody's > clocks are synchronized that well anyway, so a second here or > there doesn't matter" to the opposite. (But by the time we > realized

Re: [LEAPSECS] leap seconds in POSIX

Warner Losh wrote: > You've just scratched the surface of the problem. Indeed. (That was the third iteration of the message I sent; the first two drafts were too long to read, due to delving into too many details.) > How do I touch a file on Sat, 31 Dec 2016 18:59:60 -0500 and have > ls -l

Re: [LEAPSECS] leap seconds in POSIX

On 2020-01-27 7:38 AM, Warner Losh wrote: On Mon, Jan 27, 2020 at 8:17 AM Steve Summit > wrote: Hal Murray wrote: > Does anybody know of a good writeup of how to fix POSIX to know about > leap seconds and/or why POSIX hasn't done anything about it

Re: [LEAPSECS] leap seconds in POSIX

On Mon, Jan 27, 2020 at 8:17 AM Steve Summit wrote: > Hal Murray wrote: > > Does anybody know of a good writeup of how to fix POSIX to know about > > leap seconds and/or why POSIX hasn't done anything about it yet? > > I don't know why POSIX hasn't done anything, other than that > (1) it's an

Re: [LEAPSECS] leap seconds in POSIX

On Mon, Jan 27, 2020 at 5:35 AM Tony Finch wrote: > Zefram via LEAPSECS wrote: > > Hal Murray wrote: > > >I assume the basic idea would be something like switch the kernel to > use TAI > > >rather than UTC and implement conversion in some library routines. > > > > That's not a viable approach,

Re: [LEAPSECS] leap seconds in POSIX

On Mon 2020-01-27T10:15:56-0500 Steve Summit hath writ: > Remarkably, though, *Microsoft* of all people seized the bull by > the horns and announced more-or-less proper leapsecond support in > Windows a little while back; it might be instructive to study > that effort for lessons. I think

Re: [LEAPSECS] leap seconds in POSIX

Hal Murray wrote: > Does anybody know of a good writeup of how to fix POSIX to know about > leap seconds and/or why POSIX hasn't done anything about it yet? I don't know why POSIX hasn't done anything, other than that (1) it's an excruciatingly hard problem, made even harder by (2) the ubiquity

Re: [LEAPSECS] leap seconds in POSIX

Zefram via LEAPSECS wrote: > Hal Murray wrote: > >I assume the basic idea would be something like switch the kernel to use TAI > >rather than UTC and implement conversion in some library routines. > > That's not a viable approach, because of the wide range of uses to which > time_t is put. In

Re: [LEAPSECS] leap seconds in POSIX

Hal Murray wrote: > > Does anybody know of a good writeup of how to fix POSIX to know about leap > seconds and/or why POSIX hasn't done anything about it yet? I've made a number of presentations and whitepapers about leap seconds and problems related to them. However I'm not aware of an easy,

Re: [LEAPSECS] leap seconds in POSIX

Hal Murray wrote: >I assume the basic idea would be something like switch the kernel to use TAI >rather than UTC and implement conversion in some library routines. That's not a viable approach, because of the wide range of uses to which time_t is put. One can't rely on being able to perform

[LEAPSECS] leap seconds in POSIX

Does anybody know of a good writeup of how to fix POSIX to know about leap seconds and/or why POSIX hasn't done anything about it yet? I assume the basic idea would be something like switch the kernel to use TAI rather than UTC and implement conversion in some library routines. There is a