This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients Arfrever, belopolsky, jcea, khenriksson, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, vstinner
Date 2011-06-26.12:23:47
SpamBayes Score 3.3502162e-10
Marked as misclassified No
Message-id <>
In-reply-to <>
>> 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).
Date User Action Args
2011-06-26 12:23:48loewissetrecipients: + loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, nadeem.vawda, Arfrever, r.david.murray, rosslagerwall, khenriksson
2011-06-26 12:23:48loewislinkissue11457 messages
2011-06-26 12:23:47loewiscreate