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 ;-) _______________________________________________ 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/
