I was expecting this ticket to yield some statement about the design objectives of Instant.from-posix() and the related leap second code, but that hasn't happened yet, and it's beginning to look as though there isn't any firm objective. So I think it might be helpful to lay out the problem space.
The underlying question to ask when designing this kind of API is what class of use case it's trying to satisfy. There may be multiple use cases of interest -- there certainly will be over the module ecosystem as a whole -- and there may be a need for multiple versions of TAI<->UTC conversion to satisfy all the ones we're concerned with. For each use case we can look at what kind of requirements it places on the conversion functions, and for each possible conversion function we can look at what kind of requirements it can satisfy. Given the unavoidable split in TAI<->UTC conversion, between the known and unknown regions of the leap schedule, each possible conversion function is going to have two distinct behaviours. A caller whose interests span both regions will get either behaviour, generally not knowing which it will get. For the caller to be satisfied by a conversion function, therefore, its needs must be satisfied by each behaviour individually. Conversely, a conversion function only really provides those guarantees that are common to both of its behaviours. It's a weakest-link deal. Let's look at what the various discussed conversion semantics actually provide in this respect, to a caller spanning both regions: A: correct answers for the known region, error for the unknown region. Doesn't guarantee to produce an answer, but does guarantee that any answer produced will be correct. B: correct answers for the known region, estimate for the unknown region. Guarantees to produce a plausible estimate, not necessarily correct. C: correct answers for the known region, presumption of no leap seconds in the unknown region (current behaviour). Guarantees to produce some answer, but with no guarantee of quality, the answer may be garbage. You can see why I say that the current behaviour (C) sucks. It doesn't seem at all useful for any caller that might run into the unknown region. But let's more rigorously look at this from the point of view of caller use cases. I see these possibilities for callers' requirements: 0. require correct answers, only operating on times up to 2015. This can be satisfied by a historical leap schedule baked into the implementation, and so is satisfied by any version that we've discussed, if the input is definitely so limited. To avoid accidents, however, the caller would probably like some checking that a correct answer can actually be produced, with error signalling where it can't (behaviour A). 1. require correct answers, only operating on times for which the leap schedule has been determined by the time the call is made (so only operating up to a few weeks into the future). This is not satisfied by a schedule baked into the implementation, but can in principle be satisfied by downloading more schedule at runtime. We haven't discussed this here, but [perl #128752] has touched on it. As with case 0, error signalling where the input exceeds the intended limits is desirable. 2. require correct answers, including well into the future. This cannot be satisfied by any means short of waiting until the times of interest are no longer far in the future. Any application with this requirement has a serious design problem, which cannot be solved by any kind of cleverness in its libraries. It has to be addressed by redesigning the application. 3. require answers to be correct, but don't need to always get an answer. This requires basically conversion behaviour A, erroring on the unknown region. Optionally there could be some downloading of new leap schedule beyond what's baked into the implementation, but erroring is definitely required when that is exceeded. 4. require answers to be correct where the implementation can easily do that, and otherwise require answers consistent with what other versions of the code produce. Since some future version of the implementation will know the real leap schedule for whatever time is being asked about, being consistent with that requires producing the correct answer for all times, including those years in the future. This therefore reduces to the impossible case 2. 5. require plausible estimates. This requires basically conversion behaviour B. As with case 3, there could optionally be some downloading of new leap schedule, but that can be exceeded and so some estimation behaviour is necessary. Strictly speaking it's not necessarily required to use the actual historical leap schedule at all, but the plausibility of answers that contradict the history is low. 6. need to get answers, but have no quality requirement on what the answers are. This doesn't require the use of any estimation for the unknown region, and equally doesn't require the use of any historical leap schedule for the known region. This case can be satisfied by much simpler code that doesn't know anything about leap seconds. An application declaring this requirement isn't really requiring any form of TAI<->UTC conversion, and would be better off using its TAI or UTC times unconverted, rather than pretending that it's doing a conversion. So I see needs for conversion behaviours A and B, but behaviour C is overcomplicated for the only use case that it really satisfies (6). Over to you: what use cases are Instant.from-posix() and friends intended to satisfy? -zefram
