On 30 July 2015 at 10:54, Guido van Rossum <[email protected]> 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 > <[email protected]> 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 _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
