[tahoe-dev] [tahoe-lafs] #1133: don't claim to provide better semantics of timestamps than Python claims to provide

[tahoe-lafs]

#1133: don't claim to provide better semantics of timestamps than Python claims to
provide
-------------------------------+--------------------------------------------
     Reporter:  zooko          |       Owner:  somebody 
         Type:  defect         |      Status:  new      
     Priority:  minor          |   Milestone:  undecided
    Component:  documentation  |     Version:  1.7.0    
   Resolution:                 |    Keywords:           
Launchpad Bug:                 |  
-------------------------------+--------------------------------------------

Comment (by davidsarah):

 But no-one disagrees about whether Unix time numbers count leap seconds --
 they don't. Look:

 {{{
 >>> import calendar, time
 >>> calendar.timegm(time.strptime("2010-07-24 00:00:00 UTC",
 ...     "%Y-%m-%d %H:%M:%S %Z"))
 1279929600
 >>> 1279929600 % 86400
 0
 }}}

 If leap seconds since 1970-01-01 were included, the results would have
 been 1279929624 and 24. This is working exactly as intended; there is no
 implementation bug (although there is a bug in the Python documentation).
 The Tahoe-LAFS spec shouldn't be unnecessarily vague on a point that is
 not in contention.

 There are differences between clock implementations in exactly how to
 report the current time in the period shortly before, during, and after a
 leap second. The Unix numeric time representation can't unambiguously
 represent times around a leap second, and that's an unfixable problem for
 that representation. However it's a problem that I find it hard to get
 worked up about in the context of file timestamps; it is misguided to rely
 on those being accurate to second resolution (and a design error in
 programs like {{{make}}} that they do so). Also, note that this doesn't
 affect how Unix time numbers are converted to UTC time strings.

 Proposals to change how leap seconds are decided on, or whether any more
 will occur in future, are a red herring. For any given set of decisions
 about when leap seconds occur, such proposals don't change how either UTC
 or Unix time numbers are defined.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1133#comment:3>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage