[Javascript] OT: leap seconds (was: Is integer?)

[John Warner]

But Tedd, my program wil crash if I don't get that Leap Second down pat
<wink /> or maybe not...

John Warner


> -----Original Message-----
> From: javascript-bounces at LaTech.edu 
> [mailto:javascript-bounces at LaTech.edu] On Behalf Of tedd
> Sent: Wednesday, May 31, 2006 10:00 PM
> To: [JavaScript List]
> Subject: Re: [Javascript] OT: leap seconds (was: Is integer?)
> 
> 
> At 10:19 AM -0400 5/31/06, Steve Clay wrote:
> >Tuesday, May 30, 2006, 7:24:19 PM, tedd wrote:
> >> No, there is a lot of computation involved.
> >
> >David was just suggesting that, unlike leap years, you can't predict 
> >leap seconds with an algorithm alone; you need /observed data/.
> 
> 
> I realize that, but there's more to it.
> 
> I said:
> 
> "... you don't even want to know the computations for that."
> 
> And he replied
> 
> "No computations in the world can help you with that...."
> 
> I think he misspoke himself and I was simply stating that a 
> computation is different than an algorithm.
> 
> 
> >We don't have to worry about leap seconds because Unix time isn't 
> >really a count of seconds, but rather a mapping of the first 86400 
> >seconds of each UTC day. The mapping is discontinuous on 
> longer/shorter 
> >days (eg. added leap seconds have no Unix time equivalent), but it 
> >guarantees that adding/subtracting 86400 always gives you 
> the same time 
> >the next/previous day (if that time exists). 
> >http://en.wikipedia.org/wiki/Unix_epoch#Encoding_time_as_a_number
> >
> >Steve
> 
> Well.. throw a couple of million years into it and see if 
> your UTC day still works -- it won't.
> 
> One point here is that static "time" is based upon some 
> notion that we have conjured up -- it doesn't exist in the 
> real world and it's just like any other of our physical 
> measurements which are based upon "standards" that are only 
> standardized within our limits of observation.
> 
> Certainly an algorithm could be created to determine when to 
> add a leap second, but our limits of observations error in 
> greater magnitude than what we find acceptable for the algorithm.
> 
> I don't want to get into a discussion about this for two 
> reasons: 1) It's off-topic for this list; 2) It really 
> doesn't matter anyway.
> 
> tedd