On Thu, 7 Jan 1999 skip@calendar.com wrote:
Since time.time() returns a float and the number of days since 1901-01-01 would normally be considered an int, why not interpret single floating point args as seconds since the Unix epoch and ints or longs as days since 1901-01-01? This would be easily enough explained in the documentation and would perhaps induce less breakage in existing applications that use DateTime.
I think this sort of ambiguous contructor overloading is a dangerous practice. Actually, your scheme isn't ambiguous, but it's walking a fine line. ;-) How about a base class with no constuctor arguments, but two setting methods (SetEpoch and SetDays?), and two subclasses which unambiguously deal with each time type? The subclasses would then just be three lines each, and only hanging around for convenience. Only have time for mole hills this week, Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations