On Jan 25, 2015, at 6:06 PM, Barney Wolff wrote:
> On Sun, Jan 25, 2015 at 02:24:52PM -0800, Stephen Satchell wrote:
>>
>> Today's computers don't use clocks derived from 50- or 60-hertz
>> power-line frequency. The last computer I remember seeing with such a
>> clock was the IBM System/360.
On Sun, Jan 25, 2015 at 02:24:52PM -0800, Stephen Satchell wrote:
>
> Today's computers don't use clocks derived from 50- or 60-hertz
> power-line frequency. The last computer I remember seeing with such a
> clock was the IBM System/360. The System/370 used a motor-generator set
> for the power
On 01/25/2015 10:15 AM, valdis.kletni...@vt.edu wrote:
> It shares another problem - that doing calculations across a boundary is
> difficult. If you have a recurring timer that pops at 23:58:30 on June 30,
> and you want another one in 2 minutes. do you want a timer that the next pop
> is at 00:00
I spoke on time hacking and ntp 3 years ago at shmoocon.
On Jan 25, 2015 12:28 PM, "Ken Chase" wrote:
> I think devices would likely be fine, unless they're concerned with
> reconciling
> a leap-second updated ntp source and one that's not. Who wins?
>
> For most NTPs I would guess they're slaves
the quote from the GNU coreutils manpages on Date Input Formats:
"Our units of temporal measurement, from seconds on up to months, are so
complicated, asymmetrical and disjunctive so as to make coherent mental
reckoning in time all but impossible. Indeed, had some tyrannical god contrived
to en
On 25 Jan 2015 17:29:25 +, "John Levine" said:
> It shares with time zones the problem that you cannot tell what
> the UNIX timestamp will be for a particular future time. If
> you want to have something happen at, say, July 2 2025 at 12:00 UTC
> you can guess what the timstamp for that will
In article <201501251019290550.005c0...@smtp.24cl.home> you write:
>I've always wondered why this is such a big issue, and why it's done
>as it is.
A lot of people don't think the current approach is so great.
>In UNIX, for instance, time is measured as the number of seconds
>since the UNIX epoch
I think devices would likely be fine, unless they're concerned with reconciling
a leap-second updated ntp source and one that's not. Who wins?
For most NTPs I would guess they're slaves to whatever feed and just 'believe'
whatever they're told. (Sounds like a security hole waiting for high freque
Hi,
Java had some issues with 100% CPU usage when NTP was running during
the additional second in 2012.
http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/
Google did something different to get the extra second in:
http://googleblog.blogspot.de/2011/09/time-technology-an
On 1/25/2015 at 9:37 AM Jay Ashworth wrote:
|This June 30th, 235959UTC will be followed immediately by 235960UTC.
|
|What will /your/ devices do?
=
I've always wondered why this is such a big issue, and why it's done
as it is.
In UNIX, for instance, time is measured as the number o
This June 30th, 235959UTC will be followed immediately by 235960UTC.
What will /your/ devices do?
http://www.marketplace.org/topics/world/leap-second-deep-space-and-how-we-keep-time
Cheers,
-- jra
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
11 matches
Mail list logo
