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" <[email protected]> wrote on 05/21/2015 >> 08:02:09 AM: >> >>> From: "Eric R. Smith" <[email protected]> >>> To: Leap Second Discussion List <[email protected]> >>> 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" <[email protected]> >>> >>> On 19/05/15 08:30 PM, Joseph M Gwinn wrote: >>> >> From: "Eric R. Smith" <[email protected]> >>> >> To: Leap Second Discussion List <[email protected]> >>> >>> 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 >> [email protected] >> https://pairlist6.pair.net/mailman/listinfo/leapsecs > > _______________________________________________ > LEAPSECS mailing list > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
