[Datetime-SIG] Timeline arithmetic?

[Tim Peters]

All this violent agreement ;-) is sucking away all the free time I
have.  So I'm going to try something else:  focus on a single
_seeming_ disagreement that makes no sense to me.


[Carl]
>>> In Model A, an aware datetime (in any timezone) is nothing more than an
>>> alternate (somewhat complexified for human use) spelling of a Unix
>>> timestamp, much like a timedelta is just a complexified spelling of some
>>> number of microseconds.

[Tim]
>> A Python datetime is also just a complexified spelling of some number
>> of microseconds (since the start of 1 January 1 of the proleptic
>> Gregorian calendar).

[Carl]
> Which is a "naive time" concept, which is a pretty good sign that Python
> datetime wasn't intended to implement Model A. I thought it was already
> pretty clear that I'd figured that out by now :-)

So:

- You tell me that in model A an aware datetime is a spelling of a
Unix timestamp.

- I tell you that a Python datetime is a spelling of a different
flavor of timestamp.

- You tell me that "means" Python is using a naive time concept, and wasn't
  intended to implement model A.

Can you see why I'm baffled?  If it needs to explained, it's even more
baffling to me.  So here goes anyway:  Model A uses a very similar
concept.  Not identical, because:

- The Unix timestamp takes 1970-1-1 as its epoch, while Python's takes 1-1-1.
  They nevertheless use exactly the same proleptic calendar system.

- The Unix timestamp counts seconds, but Python's counts microseconds (on
  a platform where time_t is a floating type, a Unix timestamp can approximate
  decimal microseconds too, as fractions of a second).

- The resolution and range of a Unix timestamp vary across platforms, but Python
  defines both.

Where's a theoretically _significant_ difference?  It's simply not
true that viewing datetimes as timestamps has anything to do with
drawing a distinction between your models A and B.

An implementation of model A may or may not explicitly store the Unix
timestamp it has in mind.  From your statement that under model A it's
a "complexified" spelling of a Unix timestamp, I have to assume you
have in mind implementations where it's not explicitly stored.  In
which case it's exactly the same as in Python today:  to _find_ that
Unix timestamp, you need to convert your complexified spelling to UTC
first.

Perhaps the distinction you have in mind is that, under Model A, it's
impossible to think of an aware datetime as being anything _other_
than a Unix timestamp?  That may have been what your "nothing more"
meant.  Then, yes, there is that difference:  Python doesn't intend to
force any specific interpretation of its timestamps beyond that
they're instants in the proleptic Gregorian calendar.  Model A also
views them as instants in the proleptic Gregorian calendar, but tacks
on "and that calendar must always be viewed as being in (a proleptic
extension of an approximation to) UTC".

So maybe I understand you now after all.  But, if so, are these kinds
of seeming disagreements really worth resolving?  It requires a
seemingly unreasonable amount of time & effort to arrive at the
obvious ;-)