Torsten points to an interesting discussion of a possible bug in Pharo (but it really is the same for all Smalltalk dialects).
The basic question is what the methods #hours #seconds #days in Class Duration should answer.
The bug report says:
1. self assert: 2 days hours = 48
2. do
3. itit will fail
It’s a bug because of what is said in the comment. But please don’t even think in fixing it by changing the comment. Even a toddler would expect to see 48 hours in a duration of two days.
The poster proposes to ignore the ANSI standard and fix that to make a Duration answer its number of hours it spans over instead of the number of hours of the last unfinished day it spans over. The discussion then concentrates on whether the ANSI standard should be taken as sacred or if it was better to make things more intuitive. I’d argue it is intuitive as it is.
In fact I’d say this is not a bug at all. It’s absolutely consistent behaviour with Time, DateAndTime and so on.
Let’s say you ask somebody for the time. The natural answer is “It’s 9 hours and 23 minutes”. And this means the time consists of nine hours and 23 minutes rather than 563 minutes. You may want to know how many minutes have passed since midnight, but that’s not the “natural” way of thinking in terms of time.
If you ask somebody how long it took them to write a new iPhone application, they’d say “2 days, 8 hours and 7 minutes”. So the minutes part is 7, not (2*24*60)+(8*60)+7= 3367. You may want to ask: “and how much would that be in minutes?”. But that’s a completely different question.
So I guess the ANSI standard wasn’t so stupid at all, because the idea of the Smalltalk class library was to make the handling of things as natural as possible. There are or should be methods to answer more specific questions like “How many of unit x would that be”, like #asMinutes or #totalMinutes or the like, but I am quite comfortable with the way of thinking in the original design.
Joachims Small World 
3 responses to “Durations and the ANSI standard…”
0.9999999999999 days hours –>23
1 days hours –> 0
(1 days ) + (2 hours ) –> 1:02:00:00
oh well….
LikeLike
Not sure what you’d like to say, but
0.9999999999999 days
is less than 1 day, even if only a tiny bit. So it’s 23 hours. Where would you draw a line for incorrectness? 10^-9?
There’s no begun hour in exactly one day, so the result is zero, just as I explained in the article.
And the last one: 1 days + 2 hours is simply a day and two hours.
We may or may not like the way people defined Durations, Times, Timestamps and other Classes, But only changing Duration would neither be enough nor a good idea because it will surely break a lot of existing code. We’ve got troubles enough with Daylight Savings Time, Leap seconds and time zones. Many of them still only partly solved…
LikeLike
but ( (1 days) + (2 hours) ) hours -> 2
The (1 days) + (2 hours) response is how they answer what Joachim said was natural – 1:02:00:00, or 1 days, 2 hours, 0 minutes, 0 seconds (because, of course, computers aren’t humans, they like to be overly precise).
LikeLike