3 ms·
Linus does NOT break backwards compatibility. That is what this change implies. Which doesn't mean I disagree with changing the behaviour, but I doubt Linus wo
by yxhuvud 13y ago
Linus does NOT break backwards compatibility. That is what this change implies.
Which doesn't mean I disagree with changing the behaviour, but I doubt Linus would use that reason for that.
- marcosdumay 13y agoIt's undocummented, and very complex to use. That mail does not even have sufficient information to understand how to use this "feature". I hightly doubt anybody uses it outside of the datetime codebase. I never saw Linus complaining about changing undocummented and not used behaviour.
- sirclueless 13y agoIt is documented. That's the strongest argument against changing it: it's a documented piece of user-facing behavior. The python developers are changing it anyways because they're practical people who have decided it is more likely that people wrote bugs into their code, than that they wrote code that depended correctly on the falsiness of UTC midnight.
- einhverfr 13y agoThis is true, but if it is documented it is still sufficiently oddball to be useless. Consider: Midnight UTC, timezone EST: True Midnight UTC, timezone CET: False Midnight UTC, timezone CST: True Midnight UTC, timezone WIT: False Midnight UTC, timezone PST: True Now the problem here is that it may well be documented but it is in fact unsafe to rely on in any context. The behavior is thus irretrievably broken, documented or not. It isn't even expert-friendly. The behavior, documented or not, is irretrievably broken. After all timezones west of GMT will never have false times. If there is a use case for this behavior, I sure can't see it. Unless you like bugs appearing when you change timezones.