leapsecs-requ...@leapsecond.com said:
> Right, that's where I say its incredible nothing was done since 1972. The
> Leap Second history is fundamental, and it seems to me an obvious missing
> link. How could it have gone ignored all this time?
Back in the old days, computer clocks weren't
>> Are there any performance critical chunks of code that want to wait until N
>> years from now? I doubt it.
> With due respect, that's a crappy attitude to getting something right. You
> want to have one interface that always works that's easy to use and schedule
> with. If you don't have
On 2017-01-06 11:33 AM, Martin Burnicki wrote:
Brooks Harris wrote:
On 2017-01-05 05:56 AM, Tony Finch wrote:
Martin Burnicki wrote:
Please note that NTP servers not necessarily need to be providers for
leap second files. There are some well known sites which
Brooks Harris wrote:
>It is often repeated on LEAPSECS that "Windows doesn't even know leap
>seconds". That's just not true. It knows very well about Leap Seconds in the
>same way other systems do but it (typical desktop versions) is lazy about
>when it updates
No, what it does doesn't involve
On 2017-01-06 02:56 PM, Warner Losh wrote:
Keep in mind that leap seconds have a short shelf life. Over the next
1000 years, it's projected TAI - UT will grow to about an hour
(2500-4500 if I'm reading
https://www.ucolick.org/~sla/leapsecs/deltat.html right).
I dare say everybody on LEAPSECS
Keep in mind that leap seconds have a short shelf life. Over the next
1000 years, it's projected TAI - UT will grow to about an hour
(2500-4500 if I'm reading
https://www.ucolick.org/~sla/leapsecs/deltat.html right). In two
thousand it will be about 4 hours due to quadratic acceleration.
That's
The Gregorian calendar and UTC with leap seconds are in harmony; the customary
change-of-day time with the Gregorian calendar is midnight, and the methods
used to establish midnight throughout most of the time the Gregorian calendar
has been in use did not approach accuracy of tens of seconds.
Steffen Nurpmeso wrote:
> Martin Burnicki wrote:
> |Yes, and there needs to be an interface to timekeeping software in
> |general, i.e. provide glibc and friends with updated tz rules, and make
> |the leapsecond table available in a form that can be used by ntpd
On 2017-01-05 09:33 PM, Steve Summit wrote:
Brooks Harris wrote:
It seems to me infeasible to alter the basic behavior of time_t
because it effects every aspect of the operating system,
Absolutely. Posix time_t is untouchable, and here to stay.
POSIX time and 86400-second-day systems
Brooks Harris wrote:
> On 2017-01-05 05:56 AM, Tony Finch wrote:
>> Martin Burnicki wrote:
>>> Please note that NTP servers not necessarily need to be providers for
>>> leap second files. There are some well known sites which provide this
>>> file, and the NTP
Steve Summit wrote (offlist):
> In some ways I agree that running the kernel on TAI would be far
> preferable. I've shied away from it so as to be able to answer
> the critics who are always worrying about disconnected systems
> that might not have a source of TAI-UTC at boot time, or at all.
If
Steve Summit wrote:
>I have implemented gmtime_ts_r() and mktime_ts()
>which operate on struct timespec, and do the right thing with :60.
Have you also extended struct tm to include tm_nsec?
>I'm not ready to think about the filesystem yet (beyond thinking
>that leapsecond-aware
12 matches
Mail list logo