Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Brooks Harris
On 2020-02-01 9:39 AM, Brooks Harris wrote: On 2020-01-30 7:02 AM, Tom Van Baak wrote: Hal, I see some good comments; did you get the answer you wanted? My take: > 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

Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Michael Shields
On Sat, Feb 1, 2020 at 12:01 AM Hal Murray wrote: > Has anybody considered having time_t and the kernel keep smeared time? > > The idea is that you can convert from smeared time to TAI or UTC with leaps. > So a few new library routines should be enough for the few people who care > about leap

Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Steve Allen
On Sat 2020-02-01T00:01:22-0800 Hal Murray hath writ: > I was hoping that there would be a good white paper or blog that discussed all > the possibilities that have been considered and explained why they were > rejected. That cannot happen because of the other factor that has been in the politics

Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Brooks Harris
On 2020-02-01 3:01 AM, Hal Murray wrote: t...@leapsecond.com said: I see some good comments; did you get the answer you wanted? Nothing off list, so you have seen everything that I saw. I was hoping that there would be a good white paper or blog that discussed all the possibilities that have

Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Steve Summit
Warner Losh wrote: > But the problem with time_t are legend. I should do a talk that > lists them all. Here is, I think, the fundamental one, as I like to describe it. As Clive Feather observed years ago, There are three desirable properties for time: (1) A day is always 86400

Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Warner Losh
On Sat, Feb 1, 2020 at 3:39 PM Brooks Harris wrote: > > (As I understand it time_t is deprecated and replaced by struct timespec > in modern POSIX systems. This does not eliminate the leap-second > difficulty.) > Kinda sorta... the timespec struct has a time_t inside of it. > The leap-second

Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Brooks Harris
On 2020-01-30 7:02 AM, Tom Van Baak wrote: Hal, I see some good comments; did you get the answer you wanted? My take: > 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? No write-up. No fix. It's not

Re: [LEAPSECS] leap seconds in POSIX

2020-02-01 Thread Hal Murray
t...@leapsecond.com said: > I see some good comments; did you get the answer you wanted? Nothing off list, so you have seen everything that I saw. I was hoping that there would be a good white paper or blog that discussed all the possibilities that have been considered and explained why they

Re: [LEAPSECS] leap seconds in POSIX

2020-01-30 Thread Tom Van Baak
Hal, I see some good comments; did you get the answer you wanted? My take: > 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? No write-up. No fix. It's not possible without breaking h/w, f/w, s/w, and

Re: [LEAPSECS] leap seconds in POSIX

2020-01-28 Thread Brooks Harris
On 2020-01-28 12:15 AM, Martin Burnicki wrote: Brooks Harris wrote: Evolution of Timekeeping in Windows https://techcommunity.microsoft.com/t5/networking-blog/evolution-of-timekeeping-in-windows/ba-p/778020 Interesting that they call it "the (r)evolutionary changes to time keeping in the

Re: [LEAPSECS] leap seconds in POSIX

2020-01-28 Thread Brooks Harris
On 2020-01-27 11:52 AM, Steve Allen wrote: 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

Re: [LEAPSECS] leap seconds in POSIX

2020-01-28 Thread Tony Finch
Steve Allen wrote: > > http://hpiers.obspm.fr/eop-pc/index.php?index=C04=en > > ask to remove tidal variations Super, thanks! Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Kintyre to Ardnamurchan Point: West or southwest 4 to 6, increasing 7 or gale 8, backing south 4 or 5 later.

Re: [LEAPSECS] leap seconds in POSIX

2020-01-28 Thread Martin Burnicki
Brooks Harris wrote: > Evolution of Timekeeping in Windows > https://techcommunity.microsoft.com/t5/networking-blog/evolution-of-timekeeping-in-windows/ba-p/778020 Interesting that they call it "the (r)evolutionary changes to time keeping in the Windows operating system" when they finally managed

Re: [LEAPSECS] leap seconds in POSIX

2020-01-27 Thread Steve Allen
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

2020-01-27 Thread Tony Finch
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

2020-01-27 Thread Steve Allen
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

2020-01-27 Thread Tony Finch
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

2020-01-27 Thread Steve Summit
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

2020-01-27 Thread Brooks Harris
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

2020-01-27 Thread Warner Losh
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

2020-01-27 Thread Warner Losh
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

2020-01-27 Thread Steve Allen
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

2020-01-27 Thread Steve Summit
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

2020-01-27 Thread Tony Finch
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

2020-01-27 Thread Martin Burnicki
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

2020-01-27 Thread Zefram via LEAPSECS
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

2020-01-27 Thread Hal Murray
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