jim wrote: > Doesn't the proposal sort of imply time-zone > awareness of some kind? Or does it simply imply > UT storage? as written, it still implies time-zone awareness. the question is whether to remove that constraint (and the utc* methods). *all* early reviewers argued that time zones are a representation thingie, and doesn't belong in the abstract type. I'm tempted to agree, but I'm not sure I can explain why... > > and 2. should it support basic > > arithmetics (probably yes). > > Does this imply leap second hell, or will we > simply be vague about expectations? vague. > 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. use timetuple(). (I rather not add too much stuff to the abstract interface; the goal is to let MAL turn mxDateTime into a basetime sub- type without breaking any application code...) </F>
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