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

[Tom Van Baak]

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.

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

/tvb

  ----- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150522/7097a0e8/attachment.html>