Adam Williamson <awill...@redhat.com> added the comment:
Paul: right. This is on Linux - specifically Fedora Linux, but I don't think it
matters. glibc strftime and strptime depend on an underlying struct called
'tm'. 'man strftime' says:
%s The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000
(UTC). (TZ) (Calculated from mktime(tm).)
And 'man mktime' says:
The mktime() function converts a broken-down time structure, expressed as
local time, to calendar time representation. ... On success, mktime() returns
the calendar time (seconds since the Epoch), expressed as a value of type
time_t."
I am finding it hard to determine whether various C standards require the tm
struct and mktime and strftime and so on to handle timezones, but I'm sort of
inclining to the answer that "no they don't".
Basically I suspect what's going on in this case is that the timezone
information gets lost somewhere in the chain down from Python to system
strftime to system mktime, and Python doesn't make any adjustment to the actual
date / time values before calling system strftime to try and account for this.
I think Python must do *something* more than purely converting to a tm and
calling system strftime, though, as %Z does work, which it wouldn't if Python
was purely converting to a non-timezone-aware tm struct and calling system
strftime, I don't think...
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32988>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
