[Datetime-SIG] Clearing up terminology

[Łukasz Rekucki]

On 30 July 2015 at 10:54, Guido van Rossum <guido at python.org> wrote:
> 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).

+1

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

If the timezone is implicit, then it's not kept together with the
object. Which means that the difference is purely in the behavior of
such object, e.g. converting to UTC: naive datetime requires passing a
timezone explicitly, while your local datetime just call
get_system_timezone() and uses that. I would say if you have both a
*naive* datetime and "*zoned* datetime, the use of this kind of
datetime with implicit timezone is rather limited because you can just
use a *zoned* variant with get_system_timezone() as its TZ
_explicitly_.

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

How about *time line* arithmetic ? It's also in Noda docs and avoids
discussing what is more "human". But "strict" sounds good too.


Is there some wiki-space where this could be put to so that people
don't have too search the archives? (I'm willing to do the work and
gather the info from this thread into it).


-- 
Łukasz Rekucki