On Sun, Jun 26, 2011 at 8:23 AM, Martin v. Löwis <report@bugs.python.org> wrote:
..
>> 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;

Not quite.  This is an inherent flaw of expressing time in time zones
with DST adjustments.  Yet even if there was no DST, using local time
for file timestamps is inconvenient because you cannot easily compare
timestamps across systems.  This is similar to using locale encoding
instead of Unicode.  However this flaw does not affect timestamps
expressed in UTC.  UTC is sort of Unicode (or maybe UTF-8) of
timezones.

> the only true representation of point-in-time
> is "seconds since the epoch, as a real number" (IMO, of course).

Mathematically speaking, broken down UTC timestamp is equivalent to
"seconds since the epoch, as a real number".  There are relatively
simple mathematical formulas (defined by POSIX) that convert from one
representation to the other and back.  As long as "real number" and
broken down structure contain the sub-second data to the same
precision, the two representations are mathematically equivalent.  In
practice one representation may be more convenient than the other.
(This is somewhat similar to decimal vs. binary representation of real
numbers.) When performance is an issue "real numbers" may be more
optimal than broken down structures, but in most applications
datetime/timedelta objects are easier to deal with than abstract
numbers.

> 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 am not sure I understand this.  ISO timestamps are not more
difficult to parse than decimal numbers.  I don't think Python
supports partial timestamps and certainly partial timestamps would not
be appropriate for representing os.stat() fields.