On Mon, Nov 24, 2008 at 9:04 AM, David Fraser <report@bugs.python.org> 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().