time.strftime handling %z/%Z badly

[macintux]

BPO	38051
Nosy	@abalkin, @pganssle, @macintux

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-09-07.17:30:09.510>
labels = ['3.7']
title = 'time.strftime handling %z/%Z badly'
updated_at = <Date 2019-09-12.14:20:56.259>
user = 'https://github.com/macintux'

bugs.python.org fields:

activity = <Date 2019-09-12.14:20:56.259>
actor = 'xtreak'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2019-09-07.17:30:09.510>
creator = 'macintux'
dependencies = []
files = []
hgrepos = []
issue_num = 38051
keywords = []
message_count = 1.0
messages = ['351306']
nosy_count = 3.0
nosy_names = ['belopolsky', 'p-ganssle', 'macintux']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue38051'
versions = ['Python 3.7']

[macintux]

My apologies if this is a duplicate; there are more than a few bug reports on time and strftime, but I wasn't able to locate any reporting this specifically.

I'd be happy to do more in-depth tests with some guidance. I see that this is largely the responsibility of system libraries, but it seems likely that Python is doing something incorrectly when invoking them since the behavior is broken in both Mac and Windows.

On both my personal Mac laptop and work Windows laptop, time.strftime('%z') gives the wrong output. On Windows, '%Z' also fails.

I'm currently at -0400 (EDT) and my best guess is that because the tm_isdst flag is set to false, it's interpreting my Eastern time zone as it would be when we're no longer on DST.

Technically displaying "UTC" is also a bug, since the actual time zone is "GMT". Python 3.6 on my Amazon Linux instance handles everything correctly.

Mac, 3.7.3:

>>> epoch = int(datetime.datetime.now().timestamp())
>>> epoch
1567872682
>>> gmt = time.gmtime(epoch)
>>> gmt.tm_zone
'UTC'
>>> time.strftime('%Z', gmt)
'UTC'
>>> time.strftime('%z', gmt)
'-0500'

Python 3.7.1, Windows 7

>>> gmt.tm_zone
'UTC'
>>> time.strftime('%Z', gmt)
'Eastern Standard Time'
>>> time.strftime('%z', gmt)
'-0500'

Python 3.6.8, Amazon Linux

>>> epoch = int(datetime.datetime.now().timestamp())
>>> gmt = time.gmtime(epoch)
>>> gmt.tm_zone
'GMT'
>>> time.strftime('%Z', gmt)
'GMT'
>>> time.strftime('%z', gmt)
'+0000'

[iynehz]

This issue still exists in Python 3.10.4.

On Windows,

import time

print(time.strftime("%Y-%m-%d %H:%M:%S %z", time.gmtime()))
print(time.strftime("%Y-%m-%d %H:%M:%S %z", time.localtime()))

# outputs
# 2022-06-01 11:22:12 +0800
# 2022-06-01 19:22:12 +0800

You see strftime's %z on that gmttime() is not right.

[PierrickKoch]

Reproduced on:

• OS: Windows 10 Entreprise
• OS: Windows 11 Entreprise
• Python 3.12.2 (tags/v3.12.2:6abddd9, Feb 6 2024, 21:26:36) [MSC v.1937 64 bit (AMD64)] on win32
  from: https://www.python.org/ftp/python/3.12.2/python-3.12.2-embed-amd64.zip
• Python 3.12.3 (tags/v3.12.3:f6650f9, Apr 9 2024, 14:05:25) [MSC v.1938 64 bit (AMD64)] on win32
  from: https://www.python.org/ftp/python/3.12.3/python-3.12.3-embed-amd64.zip

>>> import time
>>> gmt = time.gmtime()
>>> gmt.tm_zone
'UTC'
>>> time.strftime('%z', gmt)
'+0100'
>>> time.strftime('%Z', gmt)
'Paris, Madrid'
>>> time.strftime('%z', time.localtime())
'+0200'
>>> time.strftime('%Z', time.localtime())
'Paris, Madrid (heure d’été)'
>>> time.strftime('%Y-%m-%dT%H:%M:%S%z', time.gmtime())
'2024-04-15T09:28:16+0100'
>>> import datetime
>>> datetime.datetime.now(datetime.timezone.utc).isoformat(timespec='seconds')
'2024-04-15T09:28:23+00:00'

Note that datetime works as expected.

[StanFromIreland]

This is a bug but it seems to be os-windows and os-mac since I cannot reproduce on Linux and neither could the user.

[picnixz]

Possibly related: #121782

[PierrickKoch]

In case this can help, in cmd:

AppData\Local\Programs\Python\Python313>python -c"import datetime as d;print(d.datetime.now(d.timezone.utc).strftime('%z'))"
+0000
AppData\Local\Programs\Python\Python313>python -c"import time;print(time.strftime('%z',time.gmtime()))"
+0100
AppData\Local\Programs\Python\Python313>set TZ=UTC
AppData\Local\Programs\Python\Python313>python -c"import time;print(time.strftime('%z',time.gmtime()))"
+0000

• cf: https://en.cppreference.com/w/c/chrono/gmtime

Could it be related to tzset ?

• https://github.com/python/cpython/blob/main/Modules/timemodule.c#L1167

[zooba]

I suspect the problem here is probably that gmtime calculates a naive time (one that has no timezone associated with it) rather than an aware time (one that knows that it's UTC).

Then when you ask the naive time to display its timezone, it's probably picking your local one (hence TZ having an effect, because that overrides your local timezone). But if you properly associate a timezone (as in the d.timezone.utc example) then it knows.

I'm not a datetime expert, and I'm not sure who's most active to have a think about this and how easily it can be changed (or even what the change is).