[LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News

[Joseph Gwinn]

On Fri, 22 May 2015 14:35:20 -0700, Tom Van Baak wrote:
> Joe,
>  
> Is there actually a free version available? That link you provided 
> wants me to pay $220 for a PDF. It also asks my for some sort of 
> personal login account for a HTML version. I'm not going there.

What's wrong with registering for free access?  That's what I do as 
well.  No salesman will call.

 
> Please advise. Or better yet, post the PDF version here on LEAPSECS.

No can do -- it's copyrighted by the IEEE and The Open Group and maybe 
ISO.  It's also huge, something like 3600 pages.


Joe

>> ----- Original Message -----
>> From: Joseph M Gwinn
>> To: Leap Second Discussion List
>> Sent: Thursday, May 21, 2015 1:09 PM
>> Subject: Re: [LEAPSECS] Look Before You Leap ? The Coming Leap 
>> Second and AWS | Hacker News
>> 
>> 
>> 
>> 
>> "LEAPSECS" <leapsecs-bounces at leapsecond.com> wrote on 05/21/2015 
>> 08:02:09 AM:
>> 
>>> From: "Eric R. Smith" <ersmith at hfx.eastlink.ca>
>>> To: Leap Second Discussion List <leapsecs at leapsecond.com>
>>> Date: 05/21/2015 08:01 AM
>>> Subject: Re: [LEAPSECS] Look Before You Leap ? The Coming Leap 
>>> Second and AWS | Hacker News
>>> Sent by: "LEAPSECS" <leapsecs-bounces at leapsecond.com>
>>> 
>>> On 19/05/15 08:30 PM, Joseph M Gwinn wrote:
>>> >> From: "Eric R. Smith" <ersmith at hfx.eastlink.ca>
>>> >> To: Leap Second Discussion List <leapsecs at leapsecond.com>
>>> >>> True UTC (with leap seconds) didn't cure a problem the 
>> committee cared
>>> >>> about, and managed to cause problems they did care about.  In short,
>>> > POSIX
>>> >>> systems have to be able to work in a cave, with no access to 
>> the sky or
>>> >>> knowledge of astronomy.
>>> >>
>>> >> If POSIX time_t were actually a count of SI seconds elapsed since the
>>> >> epoch, then a machine in a cave (with an accurate enough clock) 
>> could in
>>> >> principle maintain correct timestamps. As it stands though, 
>> POSIX time_t
>>> >> cannot be implemented without access to a UTC reference of some kind,
>>> >> i.e. access to the sky.
>>> > 
>>> > Well, while POSIX mentions SI seconds, the standard is careful 
>> to say that
>>> > these seconds are not exactly SI seconds (because UNIX workstations can
>>> > have pretty bad clocks).  And the standard specifically disclaims being
>>> > UTC, despite the appearance.  Read the standard carefully.  It 
>> is intended
>>> > and designed to support isolated operation.
>>> 
>>> I don't have the actual standard in front of me, but have seen claims
>>> that POSIX time_t is defined (for years after 1970) to be:
>>> 
>>> tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
>>>     (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
>>>     ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
>>> 
>>> and that "each and every day shall be accounted for by exactly 86400
>>> seconds". Is this correct? Since the length of the day is not in fact
>>> exactly 86400 SI seconds, it would follow that a POSIX compliant system
>>> has to know how many days have elapsed since the epoch, i.e. it needs to
>>> have some kind of access to the sky. Am I misunderstanding something?
>> 
>> Yes.  The actual standard.  HTML access is free.  
>> 
<https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=11701>
>> 
>> Look for Seconds Since the Epoch et al in the Rationale volume.
>> 
>> The disclaim of UTC is explicit.
>> 
>> There was a long thread on this on Time Nuts, where I published the 
>> details and links to the actual standard. 
>> 
>> Joe Gwinn
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
> 
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs