On 09/14/2015 03:23 PM, Random832 wrote: > Well, you could have put some reserved bits in the original pickle > format for datetime back when it was first defined, or even just allowed > passing in a longer string for future extension purposes. That you > didn't makes me wonder just where you're finding the space to put the > fold bit.
By exploiting the currently-always-0 first bit in the "minutes" byte. See https://www.python.org/dev/peps/pep-0495/#pickles It might be useful to read PEP 495 before commenting on it ;-) >> It's not so much a "good idea" as that it's the only idea consistent >> with Python's "naive time" model. Folds and gaps don't exist in naive >> time. Indeed, the _concept_ of "time zone" doesn't really exist in >> naive time. There's _inherent_ tension between the naive time model >> and the way multi-offset time zones actually behave. So it goes. > > But why does it need to be consistent? You can't compare naive datetimes > with aware ones. If you want to sort/bisect a list of datetimes, they > have to either all be naive or all be aware. So when we're talking about > how ordering works, we're fundamentally talking about how it works for > aware datetimes. What you're missing (and I was missing too, before going around in some lengthy earlier threads on this mailing list, which you may -- or may not -- find it worth your time to read) is that even "aware datetimes" in Python's datetime library always operate in "naive local clock time" for whatever timezone they are in; they aren't just alternate notations for the corresponding UTC time. This is why if you add timedelta(hours=24) to datetime(2014, 11, 2, 12, tzinfo=Eastern), you get datetime(2014, 11, 3, 12, tzinfo=Eastern), even though the difference between those two datetimes in UTC is 25 hours, not 24. In order to stay consistent with that "naive local clock time" model, all operations within a time zone must ignore the `fold` value. The `fold` value really doesn't exist at all in the naive clock time model, it's only tracked as a convenience for correct round-tripping. This implies that 1:30am fold=0 and 1:30am fold=1 are equal, and also that 1:20am fold=1 is "earlier" than 1:40am fold=0 (as long as you stay within the naive clock time model -- if you don't want to, you should convert to UTC). You may want to rail against that model. I (and some others) already did. You can go back in the archives here and read our efforts. Perhaps you'll have better luck if you try; I doubt it. But given that model, this is the only approach that makes sense. And you can get the same work done in that model. If you want to operate on the physical-time timeline, just always operate in UTC internally and only translate to "aware datetimes" at display time. That's what you probably should be doing anyway. 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/
