Martin v. Löwis <mar...@v.loewis.de> added the comment: >> any broken-down time has issues of time stamp ordering in the >> duplicate hour of switching from DST to normal time > > I understand that it is an issue of the datetime module. Can it be > solved, or is there a design issue in the module?
It's an inherent flaw of broken-down time. Don't use that representation; the only true representation of point-in-time is "seconds since the epoch, as a real number" (IMO, of course). Broken-down time has the advantage of being more easily human-readable, but is (often deliberately) incomplete (with the notion of partial time stamps) and text representations are difficult to parse. > I don't have a strong opinion on this issue, I just wanted to know > why datetime cannot be used for this issue. It's a personal preference of me (the strong objection to broken-down time representations). I believe this preference is widely shared, though. Notice how advanced file systems (NTFS, ext2) use seconds-since- the-epoch formats, whereas FAT uses broken-down time. Also notice how the daytime protocol uses broken-down time, and NTP uses seconds-since-the epoch. The major variation point in the latter is whether second fractions are represented as a separate number of not; this is also the issue here. NTP and NTFS use a single number; ext2 uses seconds/nanoseconds. Also notice that NTP does *not* have a unit that is an integral power of ten, but units of 2**-32s (ca. 233ps). NTP4 supports a resolution of 2**-64s. (To be fair, the way NTP represents time stamps can also be interpreted as a pair of second/subsecond integers). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11457> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com