New submission from Adam Williamson <awill...@redhat.com>:
Test script:
import pytz
import datetime
utc = pytz.timezone('UTC')
print(datetime.datetime(2017, 1, 1, tzinfo=utc).strftime('%s'))
Try running it with various system timezones:
[adamw@xps13k pagure (more-timezone-fun %)]$ TZ='UTC' python /tmp/test2.py
1483228800
[adamw@xps13k pagure (more-timezone-fun %)]$ TZ='America/Winnipeg' python
/tmp/test2.py
1483250400
[adamw@xps13k pagure (more-timezone-fun %)]$ TZ='America/Vancouver' python
/tmp/test2.py
1483257600
That's Python 2.7.14; same results with Python 3.6.4.
This does not seem correct. The correct Unix time for an aware datetime object
should be a constant: for 2017-01-01 00:00 UTC it *is* 1483228800 . No matter
what the system's local timezone, that should be the output of strftime('%s'),
surely. What it seems to be doing instead is just outputting the Unix time for
2017-01-01 00:00 in the system timezone.
I *do* note that strftime('%s') is completely undocumented in Python; neither
https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior
nor
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior
mentions it. However, it does exist, and is used in the real world; I found
this usage of it, and the bug, in a real project, Pagure.
----------
components: Library (Lib)
messages: 313169
nosy: adamwill
priority: normal
severity: normal
status: open
title: datetime.datetime.strftime('%s') always uses local timezone, even with
aware datetimes
versions: Python 2.7, Python 3.6
_______________________________________
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
