[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...

[Alexander Belopolsky]

On Wed, Aug 19, 2015 at 4:30 PM, Carl Meyer <carl at oddbird.net> wrote:
>
> On 08/19/2015 02:13 PM, Alexander Belopolsky wrote:
> >
> > On Wed, Aug 19, 2015 at 1:27 PM, Chris Barker <chris.barker at noaa.gov
> > <mailto:chris.barker at noaa.gov>> wrote:
> >
> >     ISO 8601 does not have a way to encode timezones.
> >
> >
> > I don't have the official $300+ PDF of the standard, but wikipedia
> > disagrees with you:
> > <https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators>.
>
> I think Chris is distinguishing between "timezones" and "UTC offsets".
> ISO 8601 can certainly encode a UTC offset, but it can't encode a
> timezone in the sense of "America/New_York".


I did understand that, of course, but general claims such as "ISO 8601 does
not have a way to encode timezones" misrepresent the actual state of
affairs.  Similarly, claims such as "Python datetime module does not
support timeline calculations with aware datetime instances" are wrong.
People who make them are likely unaware of the features added to the
datetime module in the 3.x series.

>
> Which is why it's not incorrect at all to say that "2015-03-07
> 12:00:00-0500" plus 24 hours is "2015-03-08 12:00:00-0500." To claim it
> should instead be "2015-03-08 13:00:00-0400" is making an unjustified
> assumption that "UTC-0500" must only mean "America/New_York, not during
> DST."


Actually, neither answer is wrong because "2015-03-08 12:00:00-0500" and
"2015-03-08 13:00:00-0400" is the same time and most computers (and
majority of humans) understand that.  Arguing over which answer is more
correct is like arguing whether 1 + 1 is 2 or 0b10.

>
>
> On the other hand, it's at least arguably incorrect to say that "12:00
> March 7 2015 EST" plus 24 hours is "12:00 March 8 2015 EST" rather than
> "13:00 March 8 2015 EDT". When you're working in terms of a timezone
> rather than just a UTC offset, there's a reasonable expectation to
> handle that timezone's DST transitions.


Here is how IETF Network Working Group defines a "Time Zone":

3.1.  Time Zone

   A description of the past and predicted future timekeeping practices
   of a collection of clocks that are intended to agree.

   Note that the term "time zone" does not have the common meaning of a
   region of the world at a specific UTC offset, possibly modified by
   daylight saving time.  For example, the "Central European Time" zone
   can correspond to several time zones "Europe/Berlin", "Europe/Paris",
   etc., because subregions have kept time differently in the past.


By this definition, EST, EDT, MSK, EEST are all "time zones" with a
particularly simple "description of timekeeping practices."  For example
EST can be described as keeping time in UTC minus 5 hours.   Most computers
implement such "time zones" - just set the environment variable TZ to EST
and enjoy Eastern Standard Time all year round.  The POSIX standard allows
you to describe more complicated timezones TZ=EST+05EDT,M3.2.0,M11.1.0 more
or less corresponds to the current US/Eastern DST rules.  You can use that
in your lab and all your clocks will agree with each other, but possibly
not with the world outside.  Note that the detailed descriptions of
historical timekeeping practices such as Olson's America/New_York zone file
typically refer to the simple "time zones":

$ zdump -v America/New_York | grep 2015
America/New_York  Sun Mar  8 06:59:59 2015 UTC = Sun Mar  8 01:59:59 2015
EST isdst=0
America/New_York  Sun Mar  8 07:00:00 2015 UTC = Sun Mar  8 03:00:00 2015
EDT isdst=1
America/New_York  Sun Nov  1 05:59:59 2015 UTC = Sun Nov  1 01:59:59 2015
EDT isdst=1
America/New_York  Sun Nov  1 06:00:00 2015 UTC = Sun Nov  1 01:00:00 2015
EST isdst=0

which means: in 2015 use EST until March 8, the use EDT until November 1
and then go back to EST.  This is just a complicated set of rules broken
into a series of simple "subtract X hours from UTC" rules.

Python's datetime module contains a fairly complete support for "simple"
time zones.  This support is provided by the datetime.timezone class.  If
there are cases where datetime.timezone class does not work as documented,
I would like to hear about those.

You can argue that  datetime.timezone is not a "time zone", but rather an
"offset", or you can argue that "EST" is not a time zone, but an
"abbreviation" (whatever that means), but the fact that  IETF Network
Working Group definition of time zone and Python's tzinfo class consider
simple time zones and geographical time zones to be instances of the same
concept suggests that this is the right approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150819/8f757272/attachment.html>