pep proposal : A date object for the standard library
Robin Becker
robin at jessikat.fsnet.co.uk
Thu Dec 6 08:30:31 EST 2001
More information about the Python-list mailing list
Thu Dec 6 08:30:31 EST 2001
- Previous message (by thread): pep proposal : A date object for the standard library
- Next message (by thread): pep proposal : A date object for the standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
It seems odd to define dates as a duration in days from a fixed time and then define durations in a different scale ie seconds. Wouldn't it be better to adopt the integers to represent days and the fraction to represent fractions of a day which is what various proprietary date formats do already (although with different origin). Dates and durations could then have a common underlying representation. Of course in the modern world we need nano-seconds and luckily 1+nano != 1 in ieee arithmetic so the nano second expressed in days is not effectively zero, but the pico second is off the scale and cannot be added to days with any accuracy. No matter what format is used eventually all compact date representations run out of accuracy in one direction or another so wouldn't it be wise to establish the representation limits in years and fractions of a second and make these a required part of implementations of AbstractDate derived classes. -- Robin Becker
- Previous message (by thread): pep proposal : A date object for the standard library
- Next message (by thread): pep proposal : A date object for the standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list