On 5/2/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
Yes. (I believe the C standard doesn't specify the 'epoch', just POSIX does -- for C. Regardless of that, Python's 'epoch' isn't guaranteed anywhere, and the docs you quote are probably the most authorative docs on the question.)
I would say so, yes.
As long as the value returned by time.time () is still 'seconds', and everything in the time and datetime modules properly considers the same epoch, I would say it's a bug (for third-party modules or for other parts of the standard library) to break.
Hello,
Python library reference 6.11 says, "The epoch is the point where the
time starts. On January 1st of that year, at 0 hours, the "time since
the epoch'' is zero. For Unix, the epoch is 1970."
To me this seems to suggest that the epoch may vary among platforms
and implementations as long as it's consistent. Am I correct?
Yes. (I believe the C standard doesn't specify the 'epoch', just POSIX does -- for C. Regardless of that, Python's 'epoch' isn't guaranteed anywhere, and the docs you quote are probably the most authorative docs on the question.)
For example, does it make sense to file bug reports to Python projects
assuming that time.time() returns seconds since the Unix epoch?
I would say so, yes.
I am asking because currently Python and IronPython returns very
different values for time.time() even if they run on the same computer
and at the same time.
As long as the value returned by time.time () is still 'seconds', and everything in the time and datetime modules properly considers the same epoch, I would say it's a bug (for third-party modules or for other parts of the standard library) to break.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
