Created on 2010-06-16 03:36 by belopolsky, last changed 2012-06-11 18:04 by eric.araujo.
| Messages (3) | |||
|---|---|---|---|
| msg107906 - (view) | Author: Alexander Belopolsky (belopolsky) *  |
Date: 2010-06-16 03:36 | |
I find the following quite misleading:
>>> from datetime import datetime
>>> import time
>>> time.strftime('%c %z %Z', datetime.utcnow().utctimetuple())
'Wed Jun 16 03:26:26 2010 -0500 EST'
As far as I can tell, the only other function that uses the tm_isdst flag is time.mktime, but it expect a timetuple containing local time, not UTC time.
|
|||
| msg108278 - (view) | Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-06-21 15:35 | |
With timezone.utc available in datetime module, users should be encouraged to use dt.astimezone(timezone.utc).timetuple() instead of dt.utctimetuple(). Note that the later will set tm_isdst to -1. This observation can be used to argue for either of two ways to resolve this issue: 1. Since utctimetuple() is no longer necessary, and the alternative works correctly, there is no need to fix it. Just recommend the astimezone use in the docs and explain the subtle difference. 2. Having two ways to do the same thing which have a subtle difference is not a good idea. I am leaning towards #1, but would like to hear from others. |
|||
| msg162633 - (view) | Author: Éric Araujo (eric.araujo) * |
Date: 2012-06-11 18:04 | |
> Just recommend the astimezone use in the docs and recommend creating tz-aware instances in the first time (i.e. calling now(utc) instead of utcnow()), +1. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2012-06-11 18:04:22 | eric.araujo | set | nosy:
+ eric.araujo messages: + msg162633 |
| 2011-01-11 02:04:01 | belopolsky | set | versions: + Python 3.3, - Python 3.2 |
| 2010-07-05 19:35:32 | belopolsky | set | nosy:
+ pitrou |
| 2010-06-21 15:35:16 | belopolsky | set | messages: + msg108278 |
| 2010-06-16 03:36:41 | belopolsky | create | |