Re: Is %z broken for return values of time.gmtime()?
random...@fastmail.us writes: I would argue that it _should_ be, and that it should populate it with 0 in gmtime or either with timezone/altzone or by some sort of reverse calculation in localtime, but it is not. Another problem to add to my list of reasons for my recent python-ideas proposal. Docs say that tm_gmtoff and tm_zone are available if the struct tm in the underlying C library has it. Based on that I kinda expected Cygwin to have it but apparently not. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is %z broken for return values of time.gmtime()?
On Mon, Sep 16, 2013, at 16:55, Michael Schwarz wrote: On 2013-W38-1, at 19:56, random...@fastmail.us wrote: On Mon, Sep 16, 2013, at 9:15, Michael Schwarz wrote: According to the documentation of time.gmtime(), it returns a struct_time in UTC, but %z is replaced by +0100, which is the UTC offset of my OS’s time zone without DST, but DST is currently in effect here (but was not at the timestamp passed to gmtime()). The struct_time type does not include information about what timezone it is in. Uhm … Python 3.3 introduced the tm_gmtoff member of struct_time, which contains the offset to UTC. I don't see it. Maybe it is not available on platforms that do not provide it? Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32) I would argue that it _should_ be, and that it should populate it with 0 in gmtime or either with timezone/altzone or by some sort of reverse calculation in localtime, but it is not. Another problem to add to my list of reasons for my recent python-ideas proposal. -- https://mail.python.org/mailman/listinfo/python-list
Is %z broken for return values of time.gmtime()?
I’m wondering whether this is expected: Python 3.3.2 (default, May 21 2013, 11:50:47) [GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] on darwin Type help, copyright, credits or license for more information. import time time.strftime(%F %T %z, time.gmtime(40 * 365 * 86400)) '2009-12-22 00:00:00 +0100‘ According to the documentation of time.gmtime(), it returns a struct_time in UTC, but %z is replaced by +0100, which is the UTC offset of my OS’s time zone without DST, but DST is currently in effect here (but was not at the timestamp passed to gmtime()). 40 * 365 * 86400 seconds is a bit less than 40 Years. I’m using a date near to today to rule out any peculiarities with dates that are long in the past. Using a date at which DST was active yields the same result: time.strftime(%F %T %z, time.gmtime(40.5 * 365 * 86400)) '2010-06-22 12:00:00 +0100' Why is my OS’s time zone used for formatting a struct_time with the UTC time zone? I’m running OS X 10.8.4, my OS’s time zone is set to CET/CEST. Regards Michael smime.p7s Description: S/MIME cryptographic signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Is %z broken for return values of time.gmtime()?
On Mon, Sep 16, 2013, at 9:15, Michael Schwarz wrote: According to the documentation of time.gmtime(), it returns a struct_time in UTC, but %z is replaced by +0100, which is the UTC offset of my OS’s time zone without DST, but DST is currently in effect here (but was not at the timestamp passed to gmtime()). The struct_time type does not include information about what timezone it is in. You can use datetime.datetime (e.g. datetime.datetime.fromtimestamp(40 * 365 * 86400,datetime.timezone.utc) - the datetime.datetime class has a strftime method. You should be aware that %F and %T are not portable and won't work on windows for example. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is %z broken for return values of time.gmtime()?
On 2013-W38-1, at 19:56, random...@fastmail.us wrote: On Mon, Sep 16, 2013, at 9:15, Michael Schwarz wrote: According to the documentation of time.gmtime(), it returns a struct_time in UTC, but %z is replaced by +0100, which is the UTC offset of my OS’s time zone without DST, but DST is currently in effect here (but was not at the timestamp passed to gmtime()). The struct_time type does not include information about what timezone it is in. Uhm … Python 3.3 introduced the tm_gmtoff member of struct_time, which contains the offset to UTC. I thought, %z was also introduced in Python 3.3 and so I thought it would use that field. What time zone does it use then? Does it always use the system's time zone? You can use datetime.datetime (e.g. datetime.datetime.fromtimestamp(40 * 365 * 86400,datetime.timezone.utc) - the datetime.datetime class has a strftime method. I do use that, but I was using time.localtime() to convert a POSIX timestamp to a date using the system's timezone and saw that while a struct_time produced by time.localtime() and formatted using time.strftime() shows the correct time zone (+0100 and +0200 here), it does not for a struct_time produced by time.gmtime(). I think that's strange. You should be aware that %F and %T are not portable and won't work on windows for example. I’m aware of that, but thanks. I was toying around and just needed to print the rest of the date. Regards Michael smime.p7s Description: S/MIME cryptographic signature -- https://mail.python.org/mailman/listinfo/python-list
