Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Mon, Nov 24, 2008 at 9:04 AM, David Fraser <[EMAIL PROTECTED]> wrote: ... > The point for me is that having to interact with Microsoft systems that > require times means that the conversions have to be done.
I did not see the "epoch" proposal as an interoperability with Microsoft systems feature. If this is the goal, a deeper analysis of the Microsoft standards is in order. For example, what is the valid range of the floating point timestamp? What is the range for which fromepoch (float to datetime) translation is valid? For example, if all floats are valid timestamps, then fromepoch can be limited to +/- 2**31 or to a smaller range where a float has enough precision to roundtrip microseconds. > Is it better to have everybody re-implement this, with their own bugs, or to > have a standard implementation? As far as I know, interoperability with Microsoft systems requires re-implementation of their bugs many of which are not documented. For example, OOXML requires that 1900 be treated as a leap year at least in some cases. When you write your own implementation, at least you have the source code to your own bugs. > I think it's clearly better to have it as a method on the object. Of course, > we should put docs in describing the pitfalls of this approach... Yes, having a well documented high resolution "time since epoch" to "local datetime" method in the datetime module is helpful if non-trivial timezones (such as the one Victor lives in) are supported. However, introducing floating point pitfalls into the already overcomplicated realm of calendar calculations would be a mistake. I believe the correct approach would be to extend fromtimestamp (and utcfromtimestamp) to accept a (seconds, microseconds) tuple as an alternative (and in addition) to the float timestamp. Then totimestamp can be implemented to return such tuple that fromtimestamp(totimestamp(dt) == dt for any datetime dt and totimestamp(fromtimestamp((s,us))) == (s, us) for any s and us within datetime valid range (note that s will have to be a long integer to achieve that). In addition exposing the system gettimeofday in the time module to produce (s, us) tuples may be helpful to move away from float timestamps produced by time.time(), but with totimestamp as proposed above that would be equivalent to datetime.now().totimestamp(). _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2736> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com