[Tim] >> timedelta objects only store days, seconds, and microseconds,
[Lennart Regebro <rege...@gmail.com>] > Except that they don't actually store days. They store 24 hour > periods, Not really. A timedelta is truly an integer number of microseconds, and that's all. The internal division into days, seconds and microseconds is a mixed-radix scheme designed to make extracting some common units of duration more efficient than by using division on a single long integer all the time. That's an implementation detail, although one that is exposed. > which, because of timezones changing, is not the same thing. 24 hours is 24 hours at any time in _any_ time zone, ignoring leap seconds. timedeltas are durations, not points in time. "time zones" make no sense applied to durations. > This is also clearly intended, for example timedelta allows floats, > and will convert the fraction into seconds. I suspect I'm missing your meaning here. Have a specific example to illustrate it? For example, are you talking about things like this? >>> timedelta(weeks=0.5) datetime.timedelta(3, 43200) If so, what of it? A week is _defined_ to be 7 days in timedelta, where a day is in turn defined to be 24 hours, where ... until you finally get down to microseconds. None of this has anything to do with points in time or time zones. It's entirely about duration. In the example, a week turns out to be 604800000000 microseconds. Half of that is 302400000000 microseconds. Convert that into mixed-radix days-seconds-microseconds representation, and you're left with 3 days and 43200 seconds (with 0 microseconds left over). I don't see anything remarkable about any of that - perhaps you just object to the use of the _word_ "day" in this context? It's just a word, and there's nothing remarkable either about viewing a duration of "a day" as being a duration of "24 hours". It's a timedelta - a duration. UTC offsets of any kind have nothing to do with pure durations, they only have to do with points in time. Calling "a day" 24 hours _in the context_ of a timedelta is not only unobjectionable, calling a day anything else in this entirely zone-free context would be insane ;-) > And as you have repeated many times now, the datetime module's > arithmetic is "naive" But only when staying within a single time zone. For example, if dt1 and dt2 have different tzinfo members, dt1 - dt2 acts as if both were converted to UTC first before doing subtraction. "Naive time" doesn't come into play _across_ time zones, only _within_ a time zone. When mixing time zones, there's no plausible justification for ignoring either of 'em. So they're not ignored then. > ie, it assumes that one day is always 24 hours. That's really not what it's doing, although the analogy is sometimes used in explanations. What somedatetime+timedelta really does is simpler than that: it adds the number of microseconds represented by the timedelta to somedatetime, being careful with carries across the assorted time and date components. That's all. There are no assumptions about what any of it "means". What it _doesn't_ do is consult the tzinfo member about anything, and _that's_ the true source of your complaints. It so happens that, yes, naive datetime arithmetic does always treat "a day" as 24 hours (and "a week" as 7 days, and "a minute" as 60 seconds, and so on), but not really because it's assuming anything about what days, weeks, etc "mean". It's working with microseconds, and it's giving the result you'd get from working on somedatetime.replace(tzinfo=None) instead, except it doesn't actually remove the tzinfo member. > The problem with that assumption is that it isn't true. There isn't really an assumption here. "Naive time" has no concept of "time zone", which isn't "an assumption" so much as a _requirement_ of the design. You can legitimately object that this requirement is at odds with reality in some cases. And that's true: it is. But that's also been known since the start. It's _intentionally_ at odds with reality in some cases, because it was believed that a simpler approximation to reality would be most useful most often to most applications and programmers. And you've heard from some of them here. Note that the same principle is at work in other aspects of datetime's design. For example, the proleptic Gregorian calendar is itself a simplified approximation to reality. In historical terms it's a relatively recent invention, and even now it's not used in much of the world. So what? It does little harm to most applications to pretend that, e.g., 3 March 1012 is a valid Gregorian date, but simplifies their lives, although some obsessed calendar wonk may be outraged by such a bold fiction ;-) It's all a "practicality beats purity" thing, but weaker than many such things, because in this case _sometimes_ naive arithmetic is _not_ the most practical thing. It has been in every dateime application I ever wrote, but I recognize that's not the universal experience. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
