Zoffix Znet via RT wrote: >Returning zero is much more predictable than returning a guess,
The case where the algorithm is operating in its unknown-future regime is not as easily spotted as that. The return value from the conversion is not a fixed value, it's a value that is well-formed and valid apart from (probably) being the wrong answer. But even identifying the last leap second the implementation knows about doesn't really tell you where its knowledge ends: at any time there is some period following the last scheduled leap second for which it is known that there will be no further leaps. Signalling an error would make clear whether the threshold of implementation knowledge has been passed. Another possibility, which I didn't raise earlier, would be to export a value that explicitly identifies where the threshold is: one would document that the conversion only works for times earlier than this advertised threshold. >But most importantly, I >can just patch my code for older compilers when new leap seconds are announced. That only handles leap seconds that the user code knows about specifically. If you pursue that approach you'd end up with a long and growing list of leap seconds in the user code, which rather defeats the point of using the core implementation which has such a list. The fixup code would be even more complicated than the core implementation, because it would also incorporate knowledge of which leap seconds are known to a long and growing list of core implementations. It would be easier to fully reimplement Instant.from-posix() with one's own leap second list, rather than use the core Instant.from-posix() and then fix up in this way. There certainly are good reasons to have an explicit distinction between the known and unknown regions, but this fixup scenario doesn't make much sense. Your earlier "choose any guessing algorithm" is a better motivating scenario. >Note that I was able to insert the now-known new leap second at the precise >point of time it exists, and the code gives correct result regardless >of whether I'm using a pre 2016.07 compiler. No, it does not. It does succeed in incorporating knowledge of that specific leap second, but the answer that it gives for the next gigasecond is 1 leap second, which is almost certainly not correct, just as the original 0 was almost certainly not correct. (Slightly less certain, of course, as it's a move in the direction of the likely range.) On future versions of Rakudo that know about even more leap seconds it will then give different results, progressively closer to correct, so the consistency across Rakudo versions that you achieve is rather limited. Perhaps you only intended this code to be applied to the region for which the code has knowledge of the leap schedule, in which case you have achieved what you intended and the above would be an irrelevant trifle. But you did include the next-gigasecond invocation in your version of the example. >I was able to do so *precisely* >because Rakudo does not try to guess what it doesn't know and returns 0 >instead. That's not quite true. You were able to do it that way because you know exactly what guess the older versions of Rakudo would make. That guess didn't have to be the especially crap one that there would be no more leap seconds ever; it suffices that the guess is deterministic. But this feels trifling when, as I said earlier, I find this fixup concept untenable. >I documented the behavior and the workaround method for older compilers in the >docs: >https://docs.perl6.org/type/Instant#Future_Leap_Seconds That's certainly a significant improvement, thanks. There are a couple of issues with the wording, though. "methods ... do not make any guesses" isn't really true, because the method does return a specific answer that implies a specific future leap schedule. From the point of view of the caller, it's guessing that there will never be any more leap seconds after the last one it knows about. If it signalled an error, that would constitute not guessing. Also, "leap seconds in the future" reads as if it's referring to the future of when the method is called. This could do with some rewording in accordance with what we discussed upthread, to make clear that it may apply to leap seconds in the past of the call time. The true situation is somewhat implied by the subsequent discussion of "depending on the compiler version", but that comes across as conflicting with the "in the future" rather than as clarifying it. Putting those together, I suggest that the first sentence of this doc section should read The methods that involve knowledge of leap seconds always assume that there will be no further leaps after the last leap second that the implementation knows about, which may not be the last leap second that has actually been scheduled. -zefram
