[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Matt Wozniski]

Matt Wozniski  added the comment:

> My main hesitation with this name is that I suspect users may think that 
> `use_utc_designator` means that they *unconditionally* want to use `Z` — 
> without reading the documentation (which we can assume 99% of users won't do)

I was thinking along similar lines when I used `use_utc_designator` in the PR, 
but I drew a different conclusion. I was thinking that the name 
`use_utc_designator` is sufficiently abstruse that no one would even be able to 
guess that it's referring to "Z" without actually reading the documentation for 
the parameter. In particular, I worry that `zulu=True` or `allow_Z=True` might 
lead people to make the mistake of thinking that they'll always get "Z" instead 
of "+00:00".

> A name like `utc_as_z` is definitely less... elegant, but conveys the concept 
> a bit more clearly.

This would definitely be more memorable and more approachable. If we stick with 
making it conditional on `tzname() == "UTC"`, I definitely think we want to 
have "utc" in the name of the parameter, and `utc_as_z` satisfies that.

`utc_as_z` seems reasonable to me. Let me know if you'd like me to update the 
PR.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Éric Araujo]

Éric Araujo  added the comment:

Bad idea: pass `zulu=True`

It is short, memorable if you know about it, otherwise obscure enough to push 
people to read the docs and be clear about what it does.

Also strange and far from obvious, so a bad idea.  Unless… ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Paul Ganssle]

Paul Ganssle  added the comment:

I think this approach is probably the best we can do, but I could also imagine 
that users might find it to be confusing behavior. I wonder if there's any 
informal user testing we can do?

I guess the ISO 8601 spec does call "Z" the "UTC designator", so 
`use_utc_designator` seems like approximately the right name. My main 
hesitation with this name is that I suspect users may think that 
`use_utc_designator` means that they *unconditionally* want to use `Z` — 
without reading the documentation (which we can assume 99% of users won't do) — 
you might assume that `dt.isoformat(use_utc_designator=True)` would translate 
to `dt.astimezone(timezone.utc).replace(tzinfo=None).isoformat() + "Z"`.

A name like `utc_as_z` is definitely less... elegant, but conveys the concept a 
bit more clearly. Would be worth throwing it to a poll or something before 
merging.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Matt Wozniski]

Change by Matt Wozniski :


--
keywords: +patch
pull_requests: +30131
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32041

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Matt Wozniski]

Matt Wozniski  added the comment:

> I feel like "If the offset is 00:00, use Z" is the wrong rule to use 
> conceptually

This is a really good point that I hadn't considered: `+00:00` and `Z` are 
semantically different, and just because a datetime has a UTC offset of 0 
doesn't mean it should get a `Z`; `Z` is reserved specifically for UTC.

It seems like the most semantically correct thing would be to only use `Z` if 
`tzname()` returns exactly "UTC". That would do the right thing for your London 
example for every major timezone library I'm aware of:

>>> datetime.datetime.now(zoneinfo.ZoneInfo("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(zoneinfo.ZoneInfo("UTC")).tzname()
'UTC'
>>> datetime.datetime.now(datetime.timezone.utc).tzname()
'UTC'

>>> datetime.datetime.now(dateutil.tz.gettz("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(dateutil.tz.UTC).tzname()
'UTC'

>>> datetime.datetime.now(pytz.timezone("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(pytz.UTC).tzname()
'UTC'

I think the right rule to use conceptually is "if `use_utc_designator` is true 
and the timezone name is 'UTC' then use Z". We could also check the offset, but 
I'm not convinced we need to.

--
nosy: +godlygeek

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Éric Araujo]

Éric Araujo  added the comment:

Would it be horrible to have the timezone instance control this?

--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Paul Ganssle]

New submission from Paul Ganssle :

As part of bpo-35829, it was suggested that we add the ability to output the 
"Z" suffix in `isoformat()`, so that `fromisoformat()` can both be the exact 
functional inverse of `isoformat()` and parse datetimes with "Z" outputs. I 
think that that's not a particularly compelling motivation for this, but I also 
see plenty of examples of `datetime.utcnow().isoformat() + "Z"` out there, so 
it seems like this is a feature that we would want to have *anyway*, 
particularly if we want to deprecate and remove `utcnow`.

I've spun this off into its own issue so that we can discuss how to implement 
the feature. The two obvious questions I see are:

1. What do we call the option? `use_utc_designator`, `allow_Z`, `utc_as_Z`?
2. What do we consider as "UTC"? Is it anything with +00:00? Just 
`timezone.utc`? Anything that seems like a fixed-offset zone with 0 offset?

For example, do we want this?

>>> LON = zoneinfo.ZoneInfo("Europe/London")
>>> datetime(2022, 3, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-03-01T00:00:00Z
>>> datetime(2022, 6, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-06-01T00:00:00+01:00

Another possible definition might be if the `tzinfo` is a fixed-offset zone 
with offset 0:

>>> datetime.timezone.utc.utcoffset(None)
timedelta(0)
>>> zoneinfo.ZoneInfo("UTC").utcoffset(None)
timedelta(0)
>>> dateutil.tz.UTC.utcoffset(None)
timedelta(0)
>>> pytz.UTC.utcoffset(None)
timedelta(0)

The only "odd man out" is `dateutil.tz.tzfile` objects representing fixed 
offsets, since all `dateutil.tz.tzfile` objects return `None` when `utcoffset` 
or `dst` are passed `None`. This can and will be changed in future versions.

I feel like "If the offset is 00:00, use Z" is the wrong rule to use 
conceptually, but considering that people will be opting into this behavior, it 
is more likely that they will be surprised by `datetime(2022, 3, 1, 
tzinfo=ZoneInfo("Europe/London").isoformat(utc_as_z=True)` returning 
`2022-03-01T00:00:00+00:00` than alternation between `Z` and `+00:00`.

Yet another option might be to add a completely separate function, 
`utc_isoformat(*args, **kwargs)`, which is equivalent to (in the parlance of 
the other proposal) `dt.astimezone(timezone.utc).isoformat(*args, **kwargs, 
utc_as_z=True)`.  Basically, convert any datetime to UTC and append a Z to it. 
The biggest footgun there would be people using it on naïve datetimes and not 
realizing that it would interpret them as system local times.

--
assignee: p-ganssle
components: Library (Lib)
messages: 412384
nosy: belopolsky, brett.cannon, p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: Add option to output UTC datetimes as "Z" in `.isoformat()`
type: enhancement
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com