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
