Jim Fulton wrote: > > > major issues right now is 1. should the type know about > > timezones (probably not), > > :( > > -1 > > Doesn't the proposal sort of imply time-zone > awareness of some kind? Or does it simply imply > UT storage? I tried that in early version of mxDateTime -- it fails badly. I switched to the local time assumption very early in the development. Note that Fredrik's type is an abstract type; it doesn't even store anything -- that's up to subtypes which of course can implement timezones at their liking. > > and 2. should it support basic > > arithmetics (probably yes). > > Does this imply leap second hell, or will we > simply be vague about expectations? The type will store a fixed point in time, so why worry about leap seconds (most system's don't support these anyway and if they do, the support is usually switched off per default) ? > I'd also like to see simple access methods for year, > month, day, hours, minutes, and seconds, with date parts > being one based and time parts being zero based. In the abstract base type ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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