[Datetime-SIG] Timeline arithmetic?

[Carl Meyer]

On 09/07/2015 03:44 PM, Tim Peters wrote:
> [Tim]
>>> An aware datetime _is_ a <naive datetime,
>>> tzinfo> pair, and there's a natural bijection between naive datetimes
>>> and POSIX timestamps (across all instants both can represent).
> [Carl]
>> I don't understand this, and I suspect it's at the heart of our
>> misunderstanding. I would say there are many possible bijections ....
[Tim]
> "Natural" bijection.  I gave you very simple Python code implementing
> that bijection already.  A naive datetime represents an instant in the
> proleptic Gregorian calendar.

What is your definition of "instant" here? I don't think a naive
datetime represents an instant at all; it represents a range of possible
instants, depending which timezone that naive datetime is interpreted
in. Without an offset, who knows which instant it might represent.

> So does a POSIX timestamp.  In POSIX,
> the relationship between a timestamp and calendar notation is defined
> by the C expression ("/" is truncating integer division):
> 
> timestamp = tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
>     (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
>     ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
> 
> The natural bijection, between naive datetimes and POSIX timestamps,
> is the bijection in which a naive datetime maps to/from the POSIX
> timestamp such that
> 
>      the naive datetime's calendar notation
>      is exactly equal to
>      the POSIX calendar notation
>          corresponding to that POSIX timestamp
>          as defined by the expression above.
> 
> Any other bijection is strained in comparison, hence "unnatural".
> Natural doesn't necessarily mean unique (although it does in this
> specific case - there is only one bijection satisfying the above);
> "natural" is more related to Occam's Razor ;-)

Ok, sure, because POSIX is defined in terms of the Gregorian calendar in
UTC, if you have(for some reason) _must_ compare a naive datetime to a
POSIX timestamp, it's simplest to assume the naive datetime is also in
UTC, so that their Gregorian calendars line up with no offset. I buy
that's "most natural" of the available bijections in some sense, but I'm
missing the "so what?" Under what circumstances is it reasonable to make
that assumption about a naive datetime? Rather than saying "a naive
datetime simply doesn't correspond to any particular POSIX timestamp;
they aren't comparable at all unless you have additional information,"
which is what I'd say.

I mean, I certainly hope you wouldn't want datetime to make `utcdt -
naivedt` a defined operation where it's assumed the naive datetime is UTC.

[Guido]
>>>> (POSIX timestamps are however embeddable in datetimes by using a fixed-offset tzinfo.)
[Tim]
>>> Or use a naive datetime, for all practical purposes.
[Carl]
>> Conceptually, sure, if you're willing to assume an implied
>> fixed offset timezone. "For all practical purposes," no, because
>> the _practical_ purpose of a model A tz-aware datetime is
>> to always be able to easily and unambiguously ask it "how
>> do you spell yourself in timezone X."
[Tim]
> Guido wasn't talking about any of that, and neither was I.  He was
> talking about "embedding".  That's passive with respect to thing being
> embedded.  Of course it's possible to "embed" a POSIX timestamp in a
> naive datetime - for the purpose of being embedded, it's just a
> frickin' integer ;-)

Yes, of course. Sorry, I missed the context.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150907/552ed929/attachment.sig>