[Datetime-SIG] Drop datetime's offset restrictions?

Tim Peters tim.peters at gmail.com
Thu Aug 13 04:01:04 CEST 2015


[M.-A. Lemburg]
> ...
> I'd say: simply drop the seconds offset on output. It's better to
> conform to the standard than to break interoperability:
>
> https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC

I'd say the opposite:  there are no _current_ standard or DST rules,
in the Olson database, that require sub-minute resolution.  While
there are many standard-offset rules in the database that do, they
were all retired at least dozens of years ago, and many over a century
ago.

So if someone is using such a thing, they're doing something with
long-gone historical times that presumably _requires_ knowing the
sub-minute portion of the offset.  Such uses would be ill-served by
silently discarding this information.  Python could support it fine,
so such uses would be well served by extending the standard format in
the obvious ways (to allow optional [[:]ss[.mmmmmm]] in offsets.  Any
timezone requiring such a thing would only be writable and readable in
Python, but so it goes.  If it were common enough to matter widely,
8601 would have catered to it to begin with.  By producing a
non-standard format in such cases, the user at least gets a good
chance of getting yelled at loudly if they try to read such a format
on a system that doesn't support what they're doing.


> For those few cases where you'd need them, you can fiddle
> with the time specification before the UTC offset to have
> the end result still represent the correct point in
> date/time.

This pretty much requires that the user be a bona fide expert on the
topic.  Under the alternative, a user mucking with historical
datetimes suffers no errors or surprises provided they stay entirely
within Python.  They only suffer a problem if they try to use a
non-standard 8601-ish string on a platform that doesn't support it.
That will drive them to do the obvious thing:  stick with Python,
which understands and loves them ;-)


More information about the Datetime-SIG mailing list