[issue11457] Expose nanosecond precision from system calls

[Martin v. Löwis]

Martin v. Löwis <martin at 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 <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________