(original) (raw)

> Look what happened on July 1, 1990\. At 2 AM, the clocks in Ukraine were
\> moved back one hour. So times like 01:30 AM happened twice there on that
\> day. Let's see how Python handles this situation
\>
\> $ TZ=Europe/Kiev python3
\>>>> from email.utils import localtime
\>>>> from datetime import datetime
\>>>> localtime(datetime(1990,7,1,1,30)).strftime('%c %z %Z')
\> 'Sun Jul 1 01:30:00 1990 +0400 MSD'
\>
\> So far so good, I've got the first of the two 01:30AM's. But what if I
\> want the other 01:30AM? Well,
\>
\>>>> localtime(datetime(1990,7,1,1,30), isdst=0).strftime('%c %z %Z')
\> 'Sun Jul 1 01:30:00 1990 +0300 EEST'
\>
\> gives me "the other 01:30AM", but it is counter-intuitive: I have to ask
\> for the standard (winter) time to get the daylight savings (summer) time.
\>

It looks incorrect. Here's the corresponding pytz code:

from datetime import datetime
import pytz

tz = pytz.timezone('Europe/Kiev')
print(tz.localize(datetime(1990, 7, 1, 1, 30), is\_dst=False).strftime('%c %z %Z'))
\# -> Sun Jul 1 01:30:00 1990 +0300 EEST
print(tz.localize(datetime(1990, 7, 1, 1, 30), is\_dst=True).strftime('%c %z %Z'))
\# -> Sun Jul 1 01:30:00 1990 +0400 MSD

See also "Enhance support for end-of-DST-like ambiguous time" \[1\]

\[1\] https://bugs.launchpad.net/pytz/+bug/1378150

\`email.utils.localtime()\` is broken:

from datetime import datetime
from email.utils import localtime

print(localtime(datetime(1990, 7, 1, 1, 30)).strftime('%c %z %Z'))
\# -> Sun Jul 1 01:30:00 1990 +0300 EEST
print(localtime(datetime(1990, 7, 1, 1, 30), isdst=0).strftime('%c %z %Z'))
\# -> Sun Jul 1 01:30:00 1990 +0300 EEST
print(localtime(datetime(1990, 7, 1, 1, 30), isdst=1).strftime('%c %z %Z'))
\# -> Sun Jul 1 01:30:00 1990 +0300 EEST
print(localtime(datetime(1990, 7, 1, 1, 30), isdst=-1).strftime('%c %z %Z'))
\# -> Sun Jul 1 01:30:00 1990 +0300 EEST


Versions:

$ ./python -V
Python 3.5.0a3+
$ dpkg -s tzdata | grep -i version
Version: 2015b-0ubuntu0.14.04

\> The uncertainty about how to deal with the repeated hour was the reason why
\> email.utils.localtime-like interface did not make it to the datetime
\> module.

"repeated hour" (time jumps back) can be treated like a end-of-DST
transition, to resolve ambiguities \[1\].