lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 5 Jan 2009 20:18:28 -0600
From:	Chris Adams <cmadams@...aay.net>
To:	David Newall <davidn@...idnewall.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009

Once upon a time, David Newall <davidn@...idnewall.com> said:
> We have this already; zoneinfo

How many times: zoneinfo is for offset from UTC, not changes in UTC.

> I haven't been able to find this Annex B that Alan talked of, so I can
> only go by the man page, which states, simply and explicitly, that
> time() returns seconds since Epoch, and also that Epoch is start of
> January 1 1970.  To my mind, time *does* recognise leap seconds.

Part of the rationale for SUSv3 (aka 1003.1-2001), xbd_chap04.html in my
copy:

   The topic of whether seconds since the Epoch should account for leap
   seconds has been debated on a number of occasions, and each time
   consensus was reached (with acknowledged dissent each time) that the
   majority of users are best served by treating all days identically.
   (That is, the majority of applications were judged to assume a single
   length-as measured in seconds since the Epoch-for all days. Thus,
   leap seconds are not applied to seconds since the Epoch.) Those
   applications which do care about leap seconds can determine how to
   handle them in whatever way those applications feel is best.  This
   was particularly emphasized because there was disagreement about what
   the best way of handling leap seconds might be. It is a practical
   impossibility to mandate that a conforming implementation must have a
   fixed relationship to any particular official clock (consider
   isolated systems, or systems performing "reruns" by setting the clock
   to some arbitrary time).

Now, you are wrong, the standard says so, please take this somewhere
else and stop CCing me.

-- 
Chris Adams <cmadams@...aay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists