Am 25.07.2012 03:46, schrieb Guido van Rossum: > First you will have to show how you'd have to code this *without* > nanosecond precision in datetime and how tedious that is. (I expect > that representing the timestamp as a long integer expressing a posix > timestamp times a billion would be very reasonable.)
I'd vote for two separate numbers, the first similar to JDN (Julian Day Number [1]), the second for nanoseconds per day. 3600 * 1000000 fit nicely into an unsigned 32bit int. This approach has the neat benefit that we'd get rid of the timestamp_t limitations and year 2038 bug at once. IIRC datetime used to break for dates before 1970 on some system because timestamp_t was unsigned. Python could finally support dates BC! JDN is widely used by astronomers and historians to supports a wide range of years as well as convert between calendar systems. Its day 0 is January 1, 4713 BC in proleptic Julian calendar. The conversion between Julian and Gregorian calendar makes JDN hard to use. Rata Die (Januar 1, 1 AD at midnight in proleptic Gregorian calender) sounds like a good idea. People in need for a high precision timer should also consinder TAI [2] instead of UTC as TAI doesn't have leap seconds. DJB's daemontools specifies a tai64n log format [3] that is similar to your idea. Christian [1] http://en.wikipedia.org/wiki/Julian_Day_Number [2] http://en.wikipedia.org/wiki/International_Atomic_Time [3] http://cr.yp.to/daemontools/tai64n.html _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
