> [Guido] > > ... > > - The range of datetime (1 <= year <= 9999) is much larger than the > > range of ticks (1970 <= year < 1938). I suppose it could raise an > > exception when the time is not representable as ticks. [Tim] > The range of ticks is platform-dependent, if you want to use C library > functions that accept ticks. So is the epoch -- only POSIX requires it to be 1-1-1970. I think the C standard doesn't constrain this at all (it doesn't even have to be a numeric type). In fact, non-posix systems are allowed to incorporate leap seconds into their ticks, which makes it hard to understand how ticks could be computed except by converting to local time first (a problem in itself) and then using mktime(). > > - Does it really need to be automatic? I.e., does it really need to > > be __float__()? I'd be less against this if it was an explicit > > method, e.g. dt.asposixtime(). > > Me too. totimestamp() would make most sense for a name (given existing > methods like toordinal(), fromordinal(), and fromtimestamp()). OK. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4