Showing content from http://mail.python.org/pipermail/python-dev/attachments/20150418/cc3ac706/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 16, 2015 at 1:14 AM, Alexander Belopolsky <span dir="ltr"><<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@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 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><div>> 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><span>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><span>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" target="_blank">bugs.python.org</a>>.</div><div> </div></div></div></div></blockquote><div><br></div><div>Your question below suggests that you believe it is not a bug i.e., `email.utils.localtime()` is broken *by design* unless you think it is ok to ignore `+0400 MSD`.</div><div><br></div><div>pytz works for me (I can get both `+0300 EEST` and `+0400 MSD`). I don't think `localtime()` can be fixed without the tz database. I don't know whether it should be fixed, let somebody else who can't use pytz to pioneer the issue. The purpose of the code example is to **inform** that `email.utils.localtime()` fails (it returns only +0300 EEST) in this case:</div><div><br></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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><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>
</blockquote></div><br><br clear="all"><div>No need to be so defensive about it. *""repeated hour" (time jumps back) can be treated like a end-of-DST transition, to resolve ambiguities [1]."* is just a *an example* on how to fix the problem in the same way how it is done in pytz:</div><div><br></div><div><div> >>> from datetime import datetime </div><div> >>> import pytz</div><div> >>> tz = pytz.timezone('Europe/Kiev')</div><div> >>> after = tz.localize(datetime(1990, 7, 1, 1, 30), is_dst=False)</div><div> >>> before = tz.localize(datetime(1990, 7, 1, 1, 30), is_dst=True)</div><div> >>> before < after</div><div> True</div><div> >>> before</div><div> datetime.datetime(1990, 7, 1, 1, 30, tzinfo=<DstTzInfo 'Europe/Kiev' MSD+4:00:00 DST>)</div><div> >>> after</div><div> datetime.datetime(1990, 7, 1, 1, 30, tzinfo=<DstTzInfo 'Europe/Kiev' EEST+3:00:00 DST>)</div><div> >>> before.astimezone(pytz.utc)</div><div>datetime.datetime(1990, 6, 30, 21, 30, tzinfo=<UTC>)</div><div> >>> after.astimezone(pytz.utc)</div><div>datetime.datetime(1990, 6, 30, 22, 30, tzinfo=<UTC>)</div><div> >>> before.dst()</div><div>datetime.timedelta(0, 3600)</div><div> >>> after.dst()</div><div>datetime.timedelta(0, 3600)</div><div> >>> pytz.OLSON_VERSION</div><div> '2015b'</div></div><div><br></div><div>Here's "summer time" in both cases i.e., it is not *true* end-of-DST transition (that is why I've used the word *"like"* above).</div><div><br></div>If we ignore ambiguous time that may occur more than twice then a boolean flag such as pytz's is_dst is *always* enough to resolve the ambiguity assuming we have access to the tz database.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And yes, the example demonstrates that the behavior of pytz's is_dst and localtime()'s isdst is different. The example just shows that the current behavior of localtime() doesn't allow to get `+0400 DST` (on my system, see the software versions above) and how to get it (*adopt* the pytz behavior -- you need zoneinfo for that) i.e., the message is a problem and a possible solution -- no complains.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://bugs.launchpad.net/pytz/+bug/1378150" target="_blank">https://bugs.launchpad.net/pytz/+bug/1378150</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_signature">--<br>Akira.</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