Re: [Datetime-SIG] Clearing up terminology
[Alexander Belopolsky]
As far as I understand, NodaTime to Python dictionary would have the following translations:
LocalDatetime: datetime with tzinfo=None (naive datetime)
[Guido van Rossum]
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.
[Łukasz Rekucki]
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_.
That's all fine, but my point remains, that the tz-less datetime object does *not* always mean local time. The definition I quoted from Alexander conflated the two, incorrectly IMO. [Guido]
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.
If that's what Noda uses, that's fine with me (the fewer vocabularies the better).
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).
Wikis are self-serve. Create one! -- --Guido van Rossum (python.org/~guido)
participants (1)
-
Guido van Rossum