[Datetime-SIG] Clearing up terminology

[Alexander Belopolsky]

On Wed, Jul 29, 2015 at 9:16 PM, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> wrote:
>> Fair enough: "EST is a offset", what is +1000 then?
>
> Also an offset -- but one without a name -- In the general case, a
> given offset may have more than one name.
>
> EST is one name for a +5 offset. (Or is it minus 5?) but there are
> other times on other timezones where the offset is 5.

In the UNIX/Olson world, EST, AEST, EDT etc. are all "time zones" that
have a particularly simple set of rules:

$ zdump -v EST
EST  Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 15:45:52 1901 EST isdst=0
EST  Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 15:45:52 1901 EST isdst=0
EST  Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 22:14:07 2038 EST isdst=0
EST  Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 22:14:07 2038 EST isdst=0

(For Australia/Melbourne, the output is 286 lines.)

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

$ TZ=EST date
Wed Jul 29 20:46:59 EST 2015

This matches the Python's tzinfo concept: a base class for both
datetime.timezone and pytz.timezone classes.

This means that unlike NodaTime, Python does not have different
classes for "ZonedDatetime" and "OffsetDatetime". Instead, we have a
single datetime class and different possibilities for tzinfo member.

As far as I understand, NodaTime to Python dictionary would have the
following translations:

 LocalDatetime: datetime with tzinfo=None (naive datetime)
 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.

(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.)