Bug #70335 [Com]: DateTime doesn't take into account leap seconsa

From: Date: Wed, 26 Aug 2015 08:08:21 +0000
Subject: Bug #70335 [Com]: DateTime doesn't take into account leap seconsa
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-195528@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=70335&edit=1 ID: 70335 Comment by: a at b dot c dot de Reported by: teo8976 at gmail dot com Summary: DateTime doesn't take into account leap seconsa Status: Not a bug Type: Bug Package: Date/time related PHP Version: 7.0.0RC1 Block user comment: N Private report: N New Comment: ISO 8601 mandates use of the Gregorian calendar for the representation of dates and UTC for times; it does not specify what the Gregorian calendar or UTC actually are. The Gregorian calendar is a system for generating unique identifiers for days that was introduced a few hundred years ago; "proleptic" means using it to identify dates prior to its introduction (e.g., writing "22 August 79AD" instead of "DCCCXXXII AUC IX kal. sept."). ISO 8601's contribution is limited to specifying that the date be written as "79-08-22". UTC is defined by the ITU and maintained by the BIPM. Provision for leap seconds is maintained by the IERS. Myself, I might expect that "1981-05-30T11:59:59+12:00" plus one second would be "1981-05-30T11:59:60+12:00" instead of "1981-05-31T12:00:00+12:00" - the information is there and provision is made for reading it - but if Unix timestamps are being used as the internal representation, then I can see where the information is being lost. Previous Comments: ------------------------------------------------------------------------ [2015-08-23 23:20:17] teo1978 at gmail dot com > > http://derickrethans.nl/leap-seconds-and-what-to-do-with-them.html Ok, so I was wrong about unix timestamps, since leap seconds are by definition mapped to the same unix timestamp as the previous second. Still, I don't know from where you get that proleptic Gregorian calendar "does not do leap seconds". Isn't ISO 8601 the standard that defines it? That standard does have leap seconds. From the interesting link you point to, the only relevant part I get is: "PHP uses Unix time, and does not care about leap seconds." But I don't see any explanation of why that should be acceptable when dealing with DateTime objects, which are supposed to represent dates in accordance to internetional standards. You are basically saying "we do it wrong because we don't give a ****". Every other computer system exchange dates and times between them taking into account leap seconds, and PHP just doesn't? How is that supposed to be ok? It's as if you said "PHP uses a variant of UTF-8 that doesn't have character 'ë', it's by design." ------------------------------------------------------------------------ [2015-08-23 17:32:21] derick@php.net http://derickrethans.nl/leap-seconds-and-what-to-do-with-them.html ------------------------------------------------------------------------ [2015-08-23 17:02:42] teo8976 at gmail dot com And how is it not a bug to arbitrarily adopt a calendar that is not the one the whole industrialized world currently agrees upon? ------------------------------------------------------------------------ [2015-08-23 16:57:33] teo8976 at gmail dot com How is it not a bug calling UTC what is not UTC?? ------------------------------------------------------------------------ [2015-08-23 16:45:21] derick@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP uses the proleptic Gregorian calendar which doesn't do leap seconds. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=70335 -- Edit this bug report at https://bugs.php.net/bug.php?id=70335&edit=1

« previous php.bugs (#195528) next »