Zoffix Znet via RT wrote: >This means the result of the code is dependent on the version of the >compiler and is thus inherently unpredictable, **even for historical >values.**
Absolutely right that the `future' behaviour also applies to times that are actually in the past, when running on an old Rakudo version. It's the future from the point of view of when the code was written that matters. Be careful when you speak of unpredictability. There are different classes of unpredictability that are worth distinguishing. The current implementation is unpredictable in that it can produce either the right answer or a wrong answer, and the latter can be very wrong. A version with reasonable guessing for `future' times would be qualitatively similar, in that it can produce either the right answer or a wrong answer, but the wrong answers would be quantitatively less wrong. But an implementation that throws an exception for unknown times would only be able to either produce the right answer or throw an exception, and not able to produce a wrong answer. This is still in one sense unpredictable, but it's qualitatively better, and is predictably correct in the non-exception cases. >So trying to use a "guessing formula" won't rectify the issue, since >at best it can guess, but it would add overhead execution time. This is a reasonable position to take. It is fine to punt that kind of use case to the module ecosystem. >So IMO, the current behaviour is fine as is. But this is a poor conclusion. If your position is that a good guess is no more use than a bad guess, this implies that you're only concerned about whether the answer from the function is correct or incorrect, and that an incorrect answer has no value. But with the current behaviour it's impossible to tell which you're getting, which means that the answer in any case, and therefore the function, is of no value at all. (Except when you know you're asking about historical times that all versions of Rakudo know about.) If you're not interested in making a reasonable guess for the unknown cases, the only sensible behaviour for those cases is an exception. If you really really want to bless the current behaviour, then the function needs to be documented with appropriate qualification about the quality of the answer. Since the answer for the `future' period is garbage, and the caller can't know when that period begins, you'd need to caution the user in terms such as "Only good for times up to the year 2014; when applied to any later time the result is meaningless.". Once you've got that in the API definition, of course, you might as well enforce it by having the function throw an exception for anything past 2014. -zefram
