New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instant.from-posix has false future leap second knowledge #4552
Comments
From zefram@fysh.orgThe Instant class supposedly represents times on the TAI time scale, $ ./perl6 -e 'sub leaps-between ($a, $b) { (Instant.from-posix($b) - Instant.from-posix($a)) - ($b - $a) }; say leaps-between(time - 1000000000, time); say leaps-between(time, time + 1000000000)' The first of the time intervals on which I've tried that runs from January In reality, we don't know how many leap seconds there will be in If it is really intended to guess, in cases where a definitive answer is Also, if it's a guessing function, it ought to be named in a way that -zefram |
From @zoffixznetMy feedback for RFC: Currently, the leap seconds are added as-they-get-known. For example, on my bleed Rakudo, I get 14/1 with your code, because the newly announced Dec.2016 leap second was added. This means the result of the code is dependent on the version of the compiler and is thus inherently unpredictable, **even for historical values.** 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. So IMO, the current behaviour is fine as is. If someone's application requires super precision they should make/use a module that can both utilize various guessing formulas and be updated on a particular system more easily than entire Rakudo. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetThis is a response to this Zefram's email that for some reason didn't make it to the ticket: http://www.nntp.perl.org/group/perl.perl6.compiler/2016/07/msg13370.html Quoting Zefram <zefram@fysh.org>:
But that would prevent you from working around the issue and it wouldn't be useful. Returning zero is much more predictable than returning a guess, because I can choose ./perl6 -e 'sub leaps-between ($a, $b) { (Instant.from-posix($b) - Instant.from-posix($a)) - ($b - Note that I was able to insert the now-known new leap second at the precise I documented the behavior and the workaround method for older compilers in the docs: |
From zoffix@zoffix.comPerhaps, we should evaluate some of the leap-second estimation Quoting Zefram <zefram@fysh.org>:
|
From zefram@fysh.orgZoffix Znet via RT wrote:
Absolutely right that the `future' behaviour also applies to times that Be careful when you speak of unpredictability. There are different
This is a reasonable position to take. It is fine to punt that kind of
But this is a poor conclusion. If your position is that a good guess If you're not interested in making a reasonable guess for the unknown If you really really want to bless the current behaviour, then the -zefram |
From zefram@fysh.orgZoffix Znet via RT wrote:
The case where the algorithm is operating in its unknown-future regime is Signalling an error would make clear whether the threshold of
That only handles leap seconds that the user code knows about There certainly are good reasons to have an explicit distinction between
No, it does not. It does succeed in incorporating knowledge of Perhaps you only intended this code to be applied to the region for
That's not quite true. You were able to do it that way because you know
That's certainly a significant improvement, thanks. There are a couple "methods ... do not make any guesses" isn't really true, because the Also, "leap seconds in the future" reads as if it's referring to the Putting those together, I suggest that the first sentence of this doc The methods that involve knowledge of leap seconds always assume -zefram |
From zefram@fysh.orgzoffix@zoffix.com wrote:
If you like. To be clear, I'm not pushing for the conversion to use an The preferred outcome for which I was pushing was to have either (or The starting point for leap estimation is the tidal braking effect by <http://www.ucolick.org/~sla/leapsecs/deltat.html> has some nice plots There have been many academic attempts to model and extrapolate this Excluding the linear models, it looks like none of them is compellingly To fill out our model of projected UTC, let's presume that at the The attached program implements this model, for bidirectional conversions $ perl6 utc_estimate.pl6 '2016-07-28T02:26:33 UTC' '2016-12-01T00:00:20.123 TAI' Errors are checked everywhere they should be, but the error messages are 2015-07-01T00:00:34 TAI = 2015-06-30T23:59:59 UTC That was satisfying to write.
Sure. Anything else using the leap second table runs into the same
As written, that ticket is about a more specific idea of exposing the leap -zefram |
From zefram@fysh.orguse v6; # classes for representing times on particular time scales class TaiTime { class UtcTime { # Gregorian calendar and 24-hour clock sub year_leap(Int:D $y) { $y %% 4 && ($y !%% 100 || $y %% 400) } sub year_days(Int:D $y) { year_leap($y) ?? 366 !! 365 } my @month_length = (31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31); my @nonleap_monthstarts = sub ymd_from_mjdn(Int:D $mjdn) { sub ymd_to_mjdn((Int:D $y, Int:D $m where $m >= 1 && $m <= 12, sub hms_from_mjdf(FatRat:D $mjdf where $mjdf >= 0) { sub hms_to_mjdf((Int:D $h where $h >= 0 && $h <= 23, # leap second processing my @known_leaps = <
sub leap_month_to_mjdn(Str:D $str) { sub leap_month_to_tai(Str:D $str, Int:D $dtai) { my @utc_segs = ({ my $lod_nominal_time = leap_month_to_tai("1819-12", -20); sub tai-ut1_for_tai(FatRat:D $lin) { sub dtai_for_month(Int:D $mjdn) { sub mjdn_start_month(Int:D $mjdn) { sub mjdn_next_month(Int:D $mjdn) { sub utc_from_tai_best_guess(TaiTime:D $tai) { sub utc_to_tai_best_guess(UtcTime:D $utc) { # ISO 8601 string format my regex decdig { <[0123456789]> } sub fatrat_from_str(Str:D $str) { sub iso8601_from_y(Int:D $y) { sub iso8601_to_y(Str:D $str) { sub iso8601_from_ymd((Int:D $y, Int:D $m, Int:D $d)) { sub iso8601_to_ymd(Str:D $str) { sub iso8601_from_hms((Int:D $h, Int:D $m, FatRat:D $s)) { sub iso8601_to_hms(Str:D $str) { sub iso8601_from_mjdn(Int:D $mjdn) { iso8601_from_ymd(ymd_from_mjdn($mjdn)) } sub iso8601_to_mjdn(Str:D $str) { ymd_to_mjdn(iso8601_to_ymd($str)) } sub iso8601_from_mjdf(FatRat:D $mjdf where $mjdf >= 0) { sub iso8601_to_mjdf(Str:D $str) { hms_to_mjdf(iso8601_to_hms($str)) } sub iso8601_from_mjdnf((Int:D $mjdn, FatRat:D $mjdf where $mjdf >= 0)) { sub iso8601_to_mjdnf(Str:D $str) { # main program for test sub mjdnf_from_str(Str:D $str) { for @*ARGS { |
From zefram@fysh.orgI was expecting this ticket to yield some statement about the design The underlying question to ask when designing this kind of API is what Given the unavoidable split in TAI<->UTC conversion, between the known and Let's look at what the various discussed conversion semantics actually A: correct answers for the known region, error for the unknown region. B: correct answers for the known region, estimate for the unknown region. C: correct answers for the known region, presumption of no leap seconds You can see why I say that the current behaviour (C) sucks. It doesn't But let's more rigorously look at this from the point of view of caller 0. require correct answers, only operating on times up to 2015. 1. require correct answers, only operating on times for which the leap 2. require correct answers, including well into the future. This cannot 3. require answers to be correct, but don't need to always get an 4. require answers to be correct where the implementation can easily 5. require plausible estimates. This requires basically conversion 6. need to get answers, but have no quality requirement on what the So I see needs for conversion behaviours A and B, but behaviour C is Over to you: what use cases are Instant.from-posix() and friends intended -zefram |
Migrated from rt.perl.org#126119 (status was 'open')
Searchable as RT126119$
The text was updated successfully, but these errors were encountered: