Concerning Time.TimeDiff

[Keith Wansbrough]

John Meacham wrote:

> I thought about this too, in my opinion converting to a CalendarTime is
> 'logically' functional in that the only reason the conversion would ever
> vary is with incomplete information and an approximation in the first
> place. if we consider the table of leap seconds to be an 'oracle' which
> is complete (which is the useful approximation to reality most
> applications can assume) then it IS a purely functional operation.

I thought about this last night too, and I also agree.  As long as
everyone's installations are fully up-to-date, it is a function.  When
defining behaviour, we don't take into account broken compilers, so we
shouldn't have to take into account broken/out-of-date installations,
either.

This does get a bit less clear when future dates are considered, but I
still think making it IO is overkill.  There is after all just one
table (somewhere out there in Plato's universe...), it's just that we
don't know what's in it.  We could say "the behaviour of this function
is undefined for future dates" or some such.

--KW 8-)