[Datetime-SIG] Clearing up terminology

[Guido van Rossum]

Thanks to Felipe Ocha for posting the nodatime link -- it's very useful. (I
first misread it as "no datetime". :-)

On Thu, Jul 30, 2015 at 4:10 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> [...]
> Another way to tell that "EST" is a "time zone" is because it is valid
> as a TZ environment variable value:
> [...]
>

Can we be more precise here and distinguish between a "time zone" (which is
a function from UTC to offsets) and the various *names* for time zones? It
seems that there are multiple names for some (many) time zones, and some
names also designate multiple timezones (maybe those are known as "short
names"?). Presumably a good tz database has both the mappings between names
and functions, and the functions themselves (in some DSL involving offsets
and DST rules, of course).

Also note that the functions themselves may change over time: when a local
political body changes the rules. This is then reflected in an update of
the tz database.

There's a third mapping (which doesn't concern us much here) which also
varies over time (and I don't know if the Olsen database has it): the
mapping from geographical area to time zone.


> As far as I understand, NodaTime to Python dictionary would have the
> following translations:
>
>  LocalDatetime: datetime with tzinfo=None (naive datetime)
>

I have a slight concern here. In my own brain-universe there is a
difference between a *local* datetime and a *naive* datetime. A local
datetime has an implicit timezone (the one used by the system wall clock,
or perhaps the TZ env var). A naive datetime, as intended in the original
design, has *no* timezone.

What's the difference? A local datetime has a well-defined mapping to UTC,
but a naive datetime's meaning is up to the app that manipulates it. An
example might be a world-wide publicity event that happens at noon local
time on a give date, or the broadcast time of a pre-recorded TV show (in
the US, shows are often aired at a well-known time slot, e.g. "prime time",
8pm in each time zone).

I also never meant the term "naive" to be used for the existing arithmetic
rules for tz-aware datetime objects -- I always meant "naive" to refer to
tz-less datetime objects. I would prefer something like "classic
arithmetic" for tz-aware datetime objects.

We can then introduce two new terms for different forms of arithmetic:
"human arithmetic" for the form that can do things like "+ 2 months" in a
way that (mostly) matches human expectations, and "strict arithmetic" for
the form that Lennart needs (essentially move a specific number of seconds
along UTC).

FWIW (not much, we're stuck with it now), my intention with classic
arithmetic was to approximate human arithmetic, but only for cases that
didn't require messy heuristics such as "Feb 29, 2016 plus one year" or
"Jan 31, 1956 minus 9 months". I also (naively :-) assumed that people
interested in strict arithmetic would just keep using the POSIX timestamps
used by the time module.


>  OffsetDatetime: datetime with tzinfo=datetime.timezone(offset, name)
>  ZonedDatetime: datetime with tzinfo=pytz.timezone(name)
>
> Given that all three concepts are implemented in a single
> datetime.datetime class in Python, I am not sure how helpful NodaTime
> terminology will be for our purposes.
>

They are still useful when discussing various use cases and scenarios. I
bet several heated arguments of the past days would have been cut short
more easily if these concepts had been explained earlier.

Also, the distinction in terminology helps explain the difference between
(e.g.) US EST and US/Eastern.


> (BTW, historically, early versions of Python datetime had a separate
> datetime subclass called datetimetz (IIRC), but the final design got
> rid of this unnecessary complexity.)
>

I don't believe that was ever released, but it's possible we contemplated
that and even implemented it in an early pure-Python prototype.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150730/df26cbd5/attachment-0001.html>