[Datetime-SIG] Calendar vs timespan calculations...

[Akira Li]

Łukasz Rekucki <lrekucki at gmail.com> writes:

R> On Sunday, August 2, 2015, Alexander Belopolsky <
> alexander.belopolsky at gmail.com
> <javascript:_e(%7B%7D,'cvml','alexander.belopolsky at gmail.com');>> wrote:
>
>> On Sun, Aug 2, 2015 at 9:46 AM, Guido van Rossum <guido at python.org> wrote:
>> > There's a simpler reason for ignoring leap seconds in datetime: Python's
>> > wall clock is mappable to POSIX timestamps, which also ignore leap
>> seconds
>> > (the reason being Tim's long explanation :-).
>>
>> Note that if you combine several recently made proposals, you can have
>> a fully backward-compatible solution for leap seconds.
>
>
> I don't have much time to respond now, but please don't add leap seconds.
> People are actively working to get rid of them entirely and they are never
> useful on the business level which this module is aimed at.
>

"never useful on the business level" -- you can't guarantee that your
input won't contain a leap second e.g., 2012-06-30 23:59:60.209215
see
http://stackoverflow.com/questions/21027639/python-datetime-not-accounting-for-leap-second-properly

Currently, datetime does not merely ignores leap seconds. It's hostile
to them. I don't understand why do I have to write:

  import time
  from calendar import timegm
  from datetime import datetime, timedelta

  time_string = '2012-06-30T23:59:60.209215'
  time_string, dot, us = time_string.partition('.')
  utc_time_tuple = time.strptime(time_string, "%Y-%m-%dT%H:%M:%S")
  dt = datetime(1970, 1, 1) + timedelta(seconds=timegm(utc_time_tuple))
  if dot:
      dt = dt.replace(microsecond=datetime.strptime(us, '%f').microsecond)
  print(dt)
  # -> 2012-07-01 00:00:00.209215


Instead of a simple:

  from datetime import datetime

  time_string = '2012-06-30T23:59:60.209215'
  dt = datetime.strptime(time_string, "%Y-%m-%dT%H:%M:%S.%f")
  print(dt)
  # -> 2012-07-01 00:00:00.209215

If datetime can't represent UTC time (a leap second) then it should
behave like a broken-down POSIX time consistently: the same datetime
object may refer to a different UTC time i.e., datetime(2012, 7, 1) may
refer to both 2012-07-01UTC and 2012-06-30 23:59:60UTC like 1341100800
POSIX time does:

  2012-07-01UTC          -> 1341100800
  2012-06-30 23:59:60UTC -> 1341100800

and in reverse:

  1341100800 -> 2012-07-01UTC

Related: http://bugs.python.org/issue23574