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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
