FObersteiner

2 anni fadiscuss

I guess we still like solar time a lot ;-) The point is, for date/time calculations, you need a numeric representation that increases strictly monotonically (an epoch time). If you introduce unpredictable modifications to that (leap seconds), the nice calculation falls apart, you end up with a lookup table such as the one in the IANA timezone database / TZif files (the blog post calls it the Olson library).

FObersteiner

3 anni fadiscuss

I think naive datetime would be fine, even if it resembles UTC - as long as you don't mix in a serial representation. The module documentation says, "Whether a naive object represents Coordinated Universal Time (UTC), local time, or time in some other timezone is purely up to the program, [...]". That definition goes down the drain imho once you call `.timestamp()`, which gives you Unix time as a serial representation (epoch time), which must be referenced against aware datetime, namely 1970-01-01 00:00 UTC. Same trouble vice versa (`.fromtimestamp()`).

FObersteiner

3 anni fadiscuss

No, I think pandas actually abstracts away pytz's footguns, so that's a good thing.

FObersteiner

3 anni fadiscuss

> pd.Timestamp is built on top of many awesome libraries

... pytz for example ;-)

comments