mal wrote:
> > 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.
can you elaborate?
> > 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) ?
the updated proposal adds __hash__ and __cmp__, and
the following (optional?) operations:
deltaobject = timeobject - timeobject
floatobject = float(deltaobject) # fractional seconds
timeobject = timeobject + integerobject
timeobject = timeobject + floatobject
timeobject = timeobject + deltaobject
note that "deltaobject" can be anything; the abstract type
only says that if you manage to subtract one time object from
another one of the same type, you get some object that you
can 1) convert to a float, and 2) add to another time object.
vague, but pretty useful.
> > 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 ?
Q. does mxDateTime provide separate accessors for individual
members?
</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