t Internet Exchange
http://www.midwest-ix.com
- Original Message -
From: "Harlan Stenn"
To: "Mike Hammett"
Cc: nanog@nanog.org
Sent: Wednesday, July 1, 2015 7:43:43 PM
Subject: Re: REMINDER: LEAP SECOND
Mike Hammett writes:
> It looks to have only aff
Mike Hammett writes:
> It looks to have only affected the CCR line and only those running the
> NTP and not the SNTP package.
Any idea what version of NTP or what their configuration looked like?
H
ednesday, July 1, 2015 1:20:30 PM
Subject: Re: REMINDER: LEAP SECOND
On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams wrote:
> Once upon a time, Mike Hammett said:
> > v5 is 2.4, v6 3.3.5
>
> Don't know why a 3.3.5 kernel would have deadlocked; don't think there
>
On Wed, Jul 1, 2015 at 3:17 PM, Chris Adams wrote:
> Once upon a time, Mike Hammett said:
> > v5 is 2.4, v6 3.3.5
>
> Don't know why a 3.3.5 kernel would have deadlocked; don't think there
> are any known issues that would cause that, unless there are Mikrotik
> specific patches that caused the
-
From: "Chris Adams"
To: nanog@nanog.org
Sent: Wednesday, July 1, 2015 1:17:06 PM
Subject: Re: REMINDER: LEAP SECOND
Once upon a time, Mike Hammett said:
> v5 is 2.4, v6 3.3.5
Don't know why a 3.3.5 kernel would have deadlocked; don't think there
are any known
Once upon a time, Mike Hammett said:
> v5 is 2.4, v6 3.3.5
Don't know why a 3.3.5 kernel would have deadlocked; don't think there
are any known issues that would cause that, unless there are Mikrotik
specific patches that caused the problem.
I believe the bug from the 2008 leap second was prese
: REMINDER: LEAP SECOND
Once upon a time, Rubens Kuhl said:
> Not quite. Reported crashes included 6.27, so it's possible that some other
> mitigating factor helped not to crash (like using SNTP instead of NTP,
> although there seems to be people with crashes using SNTP or no SNTP
Once upon a time, Rubens Kuhl said:
> Not quite. Reported crashes included 6.27, so it's possible that some other
> mitigating factor helped not to crash (like using SNTP instead of NTP,
> although there seems to be people with crashes using SNTP or no SNTP/NTP at
> all).
These are running Linux
On Wed, Jul 1, 2015 at 11:15 AM, Michel Luczak wrote:
> > I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28,
> 6.5 and other versions.
> >
> > Configured NTP Client in all of them.
> >
> > Anyone else had this problem?
>
> Apparently 6.27 was the safe version to have (no issu
> I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5
> and other versions.
>
> Configured NTP Client in all of them.
>
> Anyone else had this problem?
Apparently 6.27 was the safe version to have (no issues on our CRS and CCR
routers).
Regards, Michel
On Wed, Jul 1, 2015 at 10:17 AM, Mike Hammett wrote:
> It looks to have only affected the CCR line and only those running the NTP
> and not the SNTP package.
>
>
That's Mikrotik's position, but reports of some users contradict their
version (both in the need for NTP and for only affecting CCR lin
ascim"
To: nanog@nanog.org
Sent: Tuesday, June 30, 2015 8:08:28 PM
Subject: Re: REMINDER: LEAP SECOND
I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and
other versions.
Configured NTP Client in all of them.
Anyone else had this problem?
> On Jun 19
I had problems with Leap Second with mikrotik in versions 6.29.1, 6.28, 6.5 and
other versions.
Configured NTP Client in all of them.
Anyone else had this problem?
> On Jun 19, 2015, at 19:30, Baldur Norddahl wrote:
>
> On 19 June 2015 at 23:58, Harlan Stenn wrote:
>
>> Bad idea.
>>
>> Wh
* Stefan Schlesinger
> > On 25 Jun 2015, at 03:14, Damian Menscher via NANOG wrote:
> >
> > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> > comes dangerously close to your modest proposal.
>
> I wonder why Google hasn't published the patch yet. Leap smear so
On Wed, Jun 24, 2015 at 9:48 PM, Stefan Schlesinger wrote:
> > On 25 Jun 2015, at 03:14, Damian Menscher via NANOG
> wrote:
> >
> >
> http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> > comes dangerously close to your modest proposal.
>
> I wonder why Google hasn'
> On 25 Jun 2015, at 03:14, Damian Menscher via NANOG wrote:
>
> http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> comes dangerously close to your modest proposal.
>
> Damian
I wonder why Google hasn't published the patch yet. Leap smear sounds like the
sane way
Damian Menscher via NANOG wrote:
>
> http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> comes dangerously close to your modest proposal.
Also
http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/
Tony.
--
f.anthony.n.finchhttp
On Mon, Jun 22, 2015 at 7:17 AM, shawn wilson wrote:
>
> > So, what we should do is make clocks move. 9 slower half of the year
> (and then speed back up) so that we're really in line with earth's
> rotational time. I mean we've got the computers to do it (I think most RTC
> only go down to t
On 06/24/2015 12:44 PM, Matthew Huff wrote:
It looks like the safest thing for us to do is to keep our NTP
servers running and deal with any crashes/issues. That's better than
having to deal with FINRA.
For what it's worth, Red Hat pushed updates to NTP and to TZDATA. You
might want to check
Once upon a time, Gary E. Miller said:
> Depends on what your Stratum-1 is syncronized to. Some GPS time
> sources pass on the leap indicator to NTP. For example, the SiRF-3
> GPS, connected by way of gpsd, to ntpd will pass on the leap second.
Yep, my ancient old SVeeSix has been showing the l
Yo Tore!
On Wed, 24 Jun 2015 21:57:28 +0200
Tore Anderson wrote:
> If you run your own straum-1 servers, can't you just opt not to
> configure "leapfile"?
Depends on what your Stratum-1 is syncronized to. Some GPS time
sources pass on the leap indicator to NTP. For example, the SiRF-3
GPS, co
* Matthew Huff
> That won't work. Being internally sync'ed isn't good enough for
> FINRA. All the machines must be synced to an external accurate source
> at least once per trading day.
That was why I proposed to ntpdate on your (upstream-free since the
29th) NTP server(s) sometime on the 30th. T
f
Cc: nanog2
Subject: Re: REMINDER: LEAP SECOND
* Matthew Huff
> I saw that, but it says the bits are set "before 23:59" on the day of
> insertion, but I was hoping that I could shut it down later than
> 23:59:59 of the previous day (8pm EST). The reason is FINRA
> regulations
* Matthew Huff
> I saw that, but it says the bits are set "before 23:59" on the day of
> insertion, but I was hoping that I could shut it down later than
> 23:59:59 of the previous day (8pm EST). The reason is FINRA
> regulations. We have to have the time synced once per trading day
> before the o
m: matthewbhuff | Fax: 914-694-5669
-Original Message-
From: Tore Anderson [mailto:t...@fud.no]
Sent: Wednesday, June 24, 2015 3:07 PM
To: Matthew Huff
Cc: nanog2
Subject: Re: REMINDER: LEAP SECOND
* Matthew Huff
> Does anyone know what the latest that we can run our NTP servers and
&g
* Matthew Huff
> Does anyone know what the latest that we can run our NTP servers and
> not distribute the LEAP_SECOND flag to the NTP clients?
From http://support.ntp.org/bin/view/Support/NTPRelatedDefinitions:
Leap Indicator
This is a two-bit code warning of an impending leap second to
Does anyone know what the latest that we can run our NTP servers and not
distribute the LEAP_SECOND flag to the NTP clients?
> On Jun 24, 2015, at 2:33 PM, Tore Anderson wrote:
>
> * Majdi S. Abbas
>
>> On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
>>> Leap years and DST ladj
* Majdi S. Abbas
> On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
> > Leap years and DST ladjustments have never caused us any major
> > issues. It seems these code paths are well tested and work fine.
>
> I've seen quite a few people that for whatever reason insist
> on run
Once upon a time, Majdi S. Abbas said:
> "Total and utter carnage" is a bit of a stretch. Linux hosts
> that ran applications dependant on nanosleeps needed reboots. Note
> that this wasn't an issue in 2009, because the poorly tested change in
> question hadn't yet been made to the Linux
On Wed, Jun 24, 2015 at 08:33:14AM +0200, Tore Anderson wrote:
> Leap years and DST ladjustments have never caused us any major
> issues. It seems these code paths are well tested and work fine.
I've seen quite a few people that for whatever reason insist
on running systems in local time z
In your letter dated Wed, 24 Jun 2015 14:05:34 +0100 you wrote:
>Philip Homburg wrote:
>>
>> For UTC the analog approach would be to keep time in TAI internally and
>> convert to UTC when required.
>
>This is much less of a solution than you might hope, because most APIs,
>protocols, and data form
Philip Homburg wrote:
>
> For UTC the analog approach would be to keep time in TAI internally and
> convert to UTC when required.
This is much less of a solution than you might hope, because most APIs,
protocols, and data formats require UT. (Usually not UTC but a
representation isomorphic to tra
In your letter dated Wed, 24 Jun 2015 08:33:14 +0200 you wrote:
>Leap years and DST ladjustments have never caused us any major
>issues. It seems these code paths are well tested and work fine.
I seem to remember that they were not tested that well on a certain brand of
mobile devices a few years
Yes, the clock has to be bad. Been there, done that, especially early Sun x86
servers.
Leap years and DST are both things people and developers are aware of outside
of technology, leap seconds, not so much.
> On Jun 23, 2015, at 11:33 PM, Harlan Stenn wrote:
>
> Matthew Huff writes:
>> A back
o: Re: RES: REMINDER: LEAP SECOND
On Tue, 23 Jun 2015, Leonardo Oliveira Ortiz wrote:
>Guys, if we don't have NTP enable on our Linux we still have problem with leap
>second ??
Without NTP there is no leap second -- you won't even notice it.
/mark
On 24/06/2015 04:33, Harlan Stenn wrote:
> A clock crystal has to be REALLY bad for ntpd to need to step the clock.
or really virtual.
Nick
* Harlan Stenn
> Matthew Huff writes:
> > A backward step is a known issue and something that people are more
> > comfortable dealing with as it can happen on any machine with a
> > noisy clock crystal.
>
> A clock crystal has to be REALLY bad for ntpd to need to step the
> clock.
>
> > Having
Matthew Huff writes:
> A backward step is a known issue and something that people are more
> comfortable dealing with as it can happen on any machine with a noisy
> clock crystal.
A clock crystal has to be REALLY bad for ntpd to need to step the clock.
> Having 61 seconds in a minute or 86401 sec
Yo Jay!
On Tue, 23 Jun 2015 22:02:50 -0400 (EDT)
Jay Ashworth wrote:
> - Original Message -
> > From: "Harlan Stenn"
>
> > > You misunderstand the problem. :) The problem is not "clock skips
> > > backward one second," because most of the time that's not what
> > > happens. The problem
- Original Message -
> From: "Harlan Stenn"
> > You misunderstand the problem. :) The problem is not "clock skips
> > backward one second," because most of the time that's not what
> > happens. The problem is that most software does not handle it well
> > when the clock ticks ... :59 :60
A backward step is a known issue and something that people are more comfortable
dealing with as it can happen on any machine with a noisy clock crystal.
Having 61 seconds in a minute or 86401 seconds in a day is a different story.
> On Jun 23, 2015, at 8:37 PM, Harlan Stenn wrote:
>
> shawn wi
shawn wilson writes:
> On Jun 23, 2015 6:26 AM, "Nick Hilliard" wrote:
> >
>
> >
> > Blocking NTP at the NTP edge will probably work fine for most situations.
> > Bear in mind that your NTP edge is not necessarily the same as your
> network
> > edge. E.g. you might have internal GPS / radio sour
On 23/06/2015 18:23, shawn wilson wrote:
> NTP causes jumps - not skews, right?
this is implementation dependent. For normal clock differences on ntpd,
if you start it with the -x parameter, it will always slew and never step.
If you start ntpd without the -x parameter, if the calculated correct
> On Jun 23, 2015, at 1:23 PM, shawn wilson wrote:
>
> NTP causes jumps - not skews, right?
ntpdate jumps, ntpd will try to make small adjustments within a range unless -x
is specified. Many operating systems have -x as a default.
- Jared
On Jun 23, 2015 6:26 AM, "Nick Hilliard" wrote:
>
>
> Blocking NTP at the NTP edge will probably work fine for most situations.
> Bear in mind that your NTP edge is not necessarily the same as your
network
> edge. E.g. you might have internal GPS / radio sources which could
> unexpectedly inject
o: Re: REMINDER: LEAP SECOND
> On Jun 22, 2015, at 7:06 PM, Harlan Stenn wrote:
>
> Time going backwards is deadly to a number of applications.
>
> But apparently not to applications you care about.
Oh it is a problem, and most handle it very ungracefully, such as dovecot whi
iada em: terça-feira, 23 de junho de 2015 10:08
> Para: Harlan Stenn
> Cc: nanog@nanog.org
> Assunto: Re: REMINDER: LEAP SECOND
>
>
>> On Jun 22, 2015, at 7:06 PM, Harlan Stenn wrote:
>>
>> Time going backwards is deadly to a number of applications.
>>
&g
> On Jun 22, 2015, at 7:06 PM, Harlan Stenn wrote:
>
> Time going backwards is deadly to a number of applications.
>
> But apparently not to applications you care about.
Oh it is a problem, and most handle it very ungracefully, such as dovecot which
just dies:
http://wiki.dovecot.org/TimeMov
On 23/06/2015 10:25, Mel Beckman wrote:
> Why should your head explode? Possibly you’re overthinking the problem.
The problems don't relate to Harlan overthinking the problem. They relate
to developers underthinking the problem and assuming that all clocks are
monotonic and that certain rules app
Harlan,
Why should your head explode? Possibly you’re overthinking the problem. And
there is no reason (or simple way I can envision) to test my plan, as you
advise, in advance. I will just block NTP in my border router temporarily. No
need to make a mountain out of this molehill. Cisco, and m
This stuff can make my head explode.
When a leap second is added, like on 30 June 2015 at the last second of
the day, POSIX insists that the day still have 86400 seconds in it.
This makes the day longer by one second, so time has to either slow down
or move backwards.
The "dumb" way to do this is
Harlan,
Help me understand why there is a serious risk of going back in time. I
acknowledge that there is a remote chance of a backstep, but the probability
seems very low.
Suppose I disable my NTP service five minutes before a positive leap second
occurs, so that no server in my network can q
Doug Barton writes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> On 6/19/15 2:58 PM, Harlan Stenn wrote:
>> Bad idea.
>>
>> When restarting ntpd your clocks will likely be off by a second,
>> which will cause a backward step, which will force the problem you
>> claim to be avoidin
On 6/19/15 2:58 PM, Harlan Stenn wrote:
Bad idea.
When restarting ntpd your clocks will likely be off by a second, which
will cause a backward step, which will force the problem you claim to be
avoiding.
There are plenty of ways to solve this problem, and you just get to
choose what you want to
On Mon, Jun 22, 2015 at 8:44 AM, Stephane Bortzmeyer
wrote:
> On Mon, Jun 22, 2015 at 12:38:28PM +,
> Bjoern A. Zeeb wrote
> a message of 17 lines which said:
>
> > So we need a new center of the universe and switch to stardate and
> > thus solve the 32bit UNIX time problem for real this t
Tony Finch writes:
> Harlan Stenn wrote:
>
> > It's a problem with POSIX, not UTC.
> >
> > UTC is monotonic.
>
> The problems are that UTC is unpredictable, and it breaks the standard
> labelling of points in time that was used for hundreds (arguably
> thousands) of years before 1972.
You mean
shawn wilson wrote:
> So, what we should do is make clocks move. 9 slower half of the year
> (and then speed back up) so that we're really in line with earth's
> rotational time.
That's how UTC worked in the 1960s.
ftp://maia.usno.navy.mil/ser7/tai-utc.dat
It causes problems for systems that
On Mon, Jun 22, 2015, 08:29 Stephane Bortzmeyer wrote:
> On Mon, Jun 22, 2015 at 01:15:41PM +0100,
> Tony Finch wrote
> a message of 15 lines which said:
>
> > The problems are that UTC is unpredictable,
>
> That's because the earth rotation is unpredictable. Any time based on
> this buggy pla
we can just turn the internet off for an hour until the dust settles.
On (2015-06-22 14:44 +0200), Stephane Bortzmeyer wrote:
> Or simply use TAI which is the obvious time reference for Internet
> devices. Using UTC in routers is madness. Routers and Internet servers
> should use TAI internally and use UTC only when communicating with
> humans (the inferior life for
I do feel sorry for you unix/linux users having a problem in year 2038
fortunately I get another ~ 8 years... my Amiga
gets its first big problem in 2046 ;-)
http://web.archive.org/web/19981203142814/http://www.amiga.com/092098-y2k.html
alan
PS if i get to see the 2078 issue I'll be old eno
Stephane Bortzmeyer wrote:
>
> That's because the earth rotation is unpredictable. Any time based on
> this buggy planet's movements will be unpredictable. Let's patch it
> now!
http://mm.icann.org/pipermail/tz/2015-May/022280.html
http://mm.icann.org/pipermail/tz/2015-May/022281.html
http://mm.i
On Mon, Jun 22, 2015 at 12:38:28PM +,
Bjoern A. Zeeb wrote
a message of 17 lines which said:
> So we need a new center of the universe and switch to stardate and
> thus solve the 32bit UNIX time problem for real this time?
Or simply use TAI which is the obvious time reference for Internet
> On 22 Jun 2015, at 12:27 , Stephane Bortzmeyer wrote:
>
> On Mon, Jun 22, 2015 at 01:15:41PM +0100,
> Tony Finch wrote
> a message of 15 lines which said:
>
>> The problems are that UTC is unpredictable,
>
> That's because the earth rotation is unpredictable. Any time based on
> this buggy
On Mon, Jun 22, 2015 at 01:15:41PM +0100,
Tony Finch wrote
a message of 15 lines which said:
> The problems are that UTC is unpredictable,
That's because the earth rotation is unpredictable. Any time based on
this buggy planet's movements will be unpredictable. Let's patch it
now!
Harlan Stenn wrote:
> It's a problem with POSIX, not UTC.
>
> UTC is monotonic.
The problems are that UTC is unpredictable, and it breaks the standard
labelling of points in time that was used for hundreds (arguably
thousands) of years before 1972.
Tony.
--
f.anthony.n.finchhttp://dotat.at
- Original Message -
> From: "Jimmy Hess"
> On Sun, Jun 21, 2015 at 1:06 AM, wrote:
> > On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said:
> [snip]
> > I'll let the perpetrator, Richard Stallman, explain. It was a
> > kerfluffle
> > regarding whether /bin/du should use units of 1,000
On Sun, Jun 21, 2015 at 1:06 AM, wrote:
> On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said:
[snip]
> I'll let the perpetrator, Richard Stallman, explain. It was a kerfluffle
> regarding whether /bin/du should use units of 1,000 or 1024.
>
> http://karmak.org/archive/2003/01/12-14-99.epl.html
On Sat, 20 Jun 2015 19:06:29 -0400, Jay Ashworth said:
> - Original Message -
> > From: "Valdis Kletnieks"
> > I wonder how many of us are old enough to remember what that environment
> > variable *used* to be called before political correctness became
> > important.
>
> There are so many
- Original Message -
> From: "Valdis Kletnieks"
> On Sat, 20 Jun 2015 11:32:53 -0400, Jay Ashworth said:
> > - Original Message -
> >
> > > - use the posix-right timezone files
> >
> > What; not posixly-correct?
>
> I wonder how many of us are old enough to remember what that env
On Sat, 20 Jun 2015 11:32:53 -0400, Jay Ashworth said:
> - Original Message -
>
> > - use the posix-right timezone files
>
> What; not posixly-correct?
I wonder how many of us are old enough to remember what that environment
variable *used* to be called before political correctness became
On Sat, Jun 20, 2015, 14:16 Harlan Stenn wrote:
>
> shawn wilson writes:
> > ... I mean letting computers figure out slower earth rotation on the
> > fly would seem more accurate than leap seconds anyway. And then all of
> > us who do earthly things and would like simpler libraries could live
> >
shawn wilson writes:
> ... I mean letting computers figure out slower earth rotation on the
> fly would seem more accurate than leap seconds anyway. And then all of
> us who do earthly things and would like simpler libraries could live
> in peace.
Really? Have you looked in to those calculations,
On Jun 19, 2015 2:05 PM, "Saku Ytti" wrote:
>
> On (2015-06-19 13:06 -0400), Jay Ashworth wrote:
>
> Hey,
>
> > The IERS will be adding a second to time again on my birthday;
> >
> > 2015-06-30T23:59:60
>
> Hopefully this is last leap second we'll ever see. Non-monotonic time is
an
> abomination a
- Original Message -
> - use the posix-right timezone files
What; not posixly-correct?
Cheers,
-- jr ':-)' a
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Assoc
On Sat 2015-06-20T10:48:17 +0300, Saku Ytti hath writ:
> You're right. Hopefully POSIX will become monotonic next year, by removal of
> leaps from UTC.
Probably not. The ITU-R has outlined four methods for this issue, see
http://www.acma.gov.au/Industry/Spectrum/Spectrum-planning/International-pl
On (2015-06-19 21:53 +), Harlan Stenn wrote:
> It's a problem with POSIX, not UTC.
>
> UTC is monotonic.
You're right. Hopefully POSIX will become monotonic next year, by removal of
leaps from UTC.
--
++ytti
Mel Beckman writes:
> Harlan,
>
> This is cisco's recommended workaround, the ultimate conclusion of an exhau=
> stive study of all Cisco firmware and after detailed post mortem analysis o=
> f two previous Leap seconds:
>
> https://tools.cisco.com/bugsearch/bug/CSCut33302
Fair enough. And I'v
Harlan,
This is cisco's recommended workaround, the ultimate conclusion of an
exhaustive study of all Cisco firmware and after detailed post mortem analysis
of two previous Leap seconds:
https://tools.cisco.com/bugsearch/bug/CSCut33302
GSS Leap second update
CSCut33302
Description
Symptom:
Th
Baldur Norddahl writes:
> On 19 June 2015 at 23:58, Harlan Stenn wrote:
>
> > Bad idea.
> >
> > When restarting ntpd your clocks will likely be off by a second, which
> > will cause a backward step, which will force the problem you claim to be
> > avoiding.
>
> If you are afraid that your router
On 19 June 2015 at 23:58, Harlan Stenn wrote:
> Bad idea.
>
> When restarting ntpd your clocks will likely be off by a second, which
> will cause a backward step, which will force the problem you claim to be
> avoiding.
>
If you are afraid that your routers will crash due to the leapsecond, then
Bad idea.
When restarting ntpd your clocks will likely be off by a second, which
will cause a backward step, which will force the problem you claim to be
avoiding.
There are plenty of ways to solve this problem, and you just get to
choose what you want to risk/pay.
--
Harlan Stenn
http://networ
Saku Ytti writes:
> Hopefully this is last leap second we'll ever see. Non-monotonic time
> is an abomination and very very few programs measuring passage of time
> are correct. Even those which are, usually are not portable, most
> languages do not even offer monotonic time in standard libraries.
On Fri, Jun 19, 2015 at 06:29:34PM +, Mel Beckman wrote:
> The universal workaround is to simply disable NTP on your devices sometime
> on Leap-Second eave. This will let the clocks free-run over the one-second
> push, an event of which they will be blissfully ignorant. When you re-enable
>
super reliable:
http://www.newegg.com/Product/Product.aspx?Item=0N6-001Y-7
-mel
> On Jun 19, 2015, at 11:08 AM, Måns Nilsson wrote:
>
> Subject: REMINDER: LEAP SECOND Date: Fri, Jun 19, 2015 at 01:06:22PM -0400
> Quoting Jay Ashworth (j...@baylink.com):
>> The IERS will
Subject: REMINDER: LEAP SECOND Date: Fri, Jun 19, 2015 at 01:06:22PM -0400
Quoting Jay Ashworth (j...@baylink.com):
> The IERS will be adding a second to time again on my birthday;
This time around there are a number of Vendor C devices that will fail
in spectacular ways if not upgraded wit
On (2015-06-19 13:06 -0400), Jay Ashworth wrote:
Hey,
> The IERS will be adding a second to time again on my birthday;
>
> 2015-06-30T23:59:60
Hopefully this is last leap second we'll ever see. Non-monotonic time is an
abomination and very very few programs measuring passage of time are correc
So you need to wait one more second before you may pop the bottle? :)
On Fri, June 19, 2015 7:06 pm, Jay Ashworth wrote:
> The IERS will be adding a second to time again on my birthday;
>
> 2015-06-30T23:59:59
> 2015-06-30T23:59:60
> 2015-07-01T00:00:00
>
> Have fun, everyone. :-)
>
> Cheers,
> -
The IERS will be adding a second to time again on my birthday;
2015-06-30T23:59:59
2015-06-30T23:59:60
2015-07-01T00:00:00
Have fun, everyone. :-)
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Thin
I'm pretty sure University College, London (UCL) had a 360/195 on the
net in the late 1970s. I remember it had open login to I guess it was
TSO? I'd play with it but couldn't really figure out anything
interesting to do lacking all documentation and by and large
motivation other than it was kind o
Barney Wolff wrote:
>On Sun, Jan 25, 2015 at 06:42:51PM -0500, TR Shaw wrote:
>>
>> That made the transformers smaller/cooler and more efficient. I seem to
>> remember a 195 as well but maybe it
>is just CRS.
>
>Google says the 360/195 did exist. But my baby was the 360/95,
>where the first me
On Sun, Jan 25, 2015 at 06:42:51PM -0500, TR Shaw wrote:
>
> That made the transformers smaller/cooler and more efficient. I seem to
> remember a 195 as well but maybe it is just CRS.
Google says the 360/195 did exist. But my baby was the 360/95,
where the first megabyte of memory was flat-film
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
1 - 100 of 103 matches
Mail list logo
