Showing content from http://mail.python.org/pipermail/python-dev/attachments/20150415/0a295e8c/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 4:46 PM, Akira Li <span dir="ltr"><<a href="mailto:4kir4.1i@gmail.com" target="_blank">4kir4.1i@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="">> Look what happened on July 1, 1990. At 2 AM, the clocks in Ukraine were<br>
> moved back one hour. So times like 01:30 AM happened twice there on that<br>
> day. Let's see how Python handles this situation<br>
><br>
> $ TZ=Europe/Kiev python3<br>
>>>> from email.utils import localtime<br>
>>>> from datetime imp<span class="" tabindex="0"><span class="">ort </span></span>datetime<br>
>>>> localtime(datetime(1990,7,1,1,30)).strftime('%c %z %Z')<br>
> 'Sun Jul 1 01:30:00 1990 +0400 MSD'<br>
><br>
> So far so good, I've got the first of the two 01:30AM's. But what if I<br>
> want the other 01:30AM? Well,<br>
><br>
>>>> localtime(datetime(1990,7,1,1,30), isdst=0).strftime('%c %z %Z')<br>
> 'Sun Jul 1 01:30:00 1990 +0300 EEST'<br>
><br>
> gives me "the other 01:30AM", but it is counter-intuitive: I have to ask<br>
> for the standard (winter)Â time to get the daylight savings (summe<span class="" tabindex="0"><span class="">r) time</span></span>.<br>
><br>
<br>
</div></div>It looks incorrect. Here's the corresponding pytz code:<br>
<br>
 from datetime import datetime<br>
 import pytz<br>
<br>
 tz = pytz.timezone('Europe/Kiev')<br>
 print(tz.localize(datetime(1990, 7, 1, 1, 30), is_dst=False).strftime('%c %z %Z'))<br>
 # -> Sun Jul 1 01:30:00 1990 +0300 EEST<br>
 print(tz.localize(datetime(1990, 7, 1, 1, 30), is_dst=True).strftime('%c %z %Z'))<br>
 # -> Sun Jul 1 01:30:00 1990 +0400 MSD<br>
<br>
See also "Enhance support for end-of-DST-like ambiguous time" [1]<br>
<br>
[1] <a href="https://bugs.launchpad.net/pytz/+bug/1378150" target="_blank">https://bugs.launchpad.net/pytz/+bug/1378150</a><br>
<br>
`email.utils.localtime()` is broken:<br></blockquote><div><br></div><div>If you think there is a bug in email.utils.localtime - please open an issue at <<a href="http://bugs.python.org">bugs.python.org</a>>.</div><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
 from datetime import datetime<br>
 from email.utils import localtime<br>
<br>
 print(localtime(datetime(1990, 7, 1, 1, 30)).strftime('%c %z %Z'))<br>
 # -> Sun Jul 1 01:30:00 1990 +0300 EEST<br>
 print(localtime(datetime(1990, 7, 1, 1, 30), isdst=0).strftime('%c %z %Z'))<br>
 # -> Sun Jul 1 01:30:00 1990 +0300 EEST<br>
 print(localtime(datetime(1990, 7, 1, 1, 30), isdst=1).strftime('%c %z %Z'))<br>
 # -> Sun Jul 1 01:30:00 1990 +0300 EEST<br>
 print(localtime(datetime(1990, 7, 1, 1, 30), isdst=-1).strftime('%c %z %Z'))<br>
 # -> Sun Jul 1 01:30:00 1990 +0300 EEST<br>
<br>
<br>
Versions:<br>
<br>
 $ ./python -V<br>
 Python 3.5.0a3+<br>
 $ dpkg -s tzdata | grep -i version<br>
 Version: 2015b-0ubuntu0.14.04<br>
<span class=""><br>
> The uncertainty about how to deal with the repeated hour was the reason why<br>
> email.utils.localtime-like interface did not make it to the datetime<br>
> module.<br>
<br>
</span>"repeated hour" (time jumps back) can be treated like a end-of-DST<br>
transition, to resolve ambiguities [1].</blockquote></div><br>I don't understand what you are complaining about. It is quite possible that pytz uses is_dst flag differently from the way email.utils.localtime uses isdst.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I was not able to find a good description of what is_dst means in pytz, but localtime's isdst is documented as follows: </div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">  a positive or zero value for *isdst* causes localtime to</div><div class="gmail_extra">  presume initially that summer time (for example, Daylight Saving Time)</div><div class="gmail_extra">  is or is not (respectively) in effect for the specified time.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Can you demonstrate that email.utils.localtime does not behave as documented?</div></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4