Re: [LEAPSECS] Lets get REAL about time.
On 23 Jan 2012 at 7:24, Steve Allen wrote: > The same is true for most future events in any time scale. > The most evident example is the countdown for a launch. Or the time left in a football or basketball game; it ticks downward in (presumably SI) seconds, but the clock starts and stops at various times, some unpredictable (like when somebody calls time out) and some more predictable (the clock in football always stops for the two minute warning, though if a play is in progress then it might actually go down to 1:58 or so). I find soccer rather more inscrutable, with a clock that counts upward without stopping, but then has an unpredictable-length added time tacked on by the officials which ends when they say it does, without precise advance warning. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Daniel R. Tobias wrote: > Usually such events are only "fixed" relative to local civil time in the > place where the event is to take place, in which case they would shift > relative to "real" TAI time with all changes to the local time, from leap > seconds to changes in time zone boundaries and daylight saving rules. Virtually all of our meetings take place in more than one place since we have sites in Arizona and Chile, Corporate HQ in DC, partners in California and Hawaii (and a dozen other places). I imagine this is not atypical these days. Scheduling changes are needed when DST kicks in in the U.S. (though not in Arizona) and six months (give or take) out of sync in Chile. Whatever our individual positions on the issues, they will be better served by collecting complete and accurate use cases and engineering requirements. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Wonder if this will describe the ultimate outcome of the implementation of this proposed timekeeping functionality: http://xkcd.com/927/ -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Mon 2012/01/23 08:05:15 -, "Poul-Henning Kamp" wrote
in a message to: Mark Calabretta
and copied to: Leap Second Discussion List ,
"Keith Winstein"
>>So effectively what is needed is a function to subtract two tm structs.
>
>You can always compare them ("is date1 before, the same or after date2")
OK.
>but you cannot subtract them and get a precise time-difference, if they
>span a potential leap-second application.
Not an exact time difference, but you can get one to a level of accuracy
that is more than adequate for all but the most stringent purposes.
This is already the case when subtracting two time_t values converted
from tm structs, whether past or future, because mktime() can't account
for leap seconds. However, if one of the times is "now", then the
result becomes more accurate as the difference gets smaller. That's the
important property for triggering an event.
>But a similar problem appears as soon as we try to compare or subtract
>two timestamps in two different civil timescales, which includes
>UTC in my design: Som looney politician might change the timezone
>before we get there.
I agree with not allowing users to perform undefined conversions to/from
realtime_t. So when converting between it and UTC, the API returns EDOM
(E2BIG) for conversions beyond the leap second table. No argument there.
>>Currently this is done by the user by converting the two structs to
>>time_t and subtracting those. The implicit assumption is that that
>>would now be done via realtime_t.
>
>No, that will fail if we don't have a leapsecond table valid for
>both timestamps.
Correct. So something must be provided to replace the implicit
assumption that it would be done via realtime_t (assuming that time_t
goes away).
In a nutshell, the problem is to allow future dates to be stored AND to
provide a simple means of computing the approximate timespan till that
date occurs. So far we agree that the date can only be stored in a tm
struct, and that in general it won't be possible to convert it to
realtime_t for computing the timespan.
I offered the solution of providing a function to subtract two tm
structs. It would be included with the realtime_t suite of routines
even though it doesn't deal with realtime_t values. This is how the
man page might start:
int tmdiff(const struct tm *tm1, const struct tm *tm2, double *diff);
Return the time interval, *tm2 - *tm1, in SI seconds. An approximate
result may be returned where one or both represent a future time.
When differencing UTCs more than 175 days in the future, a worst case
error of one second in 175 days (1 part in 15e6) may arise from future
unannounced leap seconds. When differencing particular time zones, an
error of one or possibly two hours may arise over short periods due to
late announcements of changes in daylight saving time.
As I said, these uncertainties are already inherent in differencing two
time_t values converted from future-valued tm structs, yet life still
goes on.
Regards, Mark
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 22 Jan 2012 at 0:09, Poul-Henning Kamp wrote: > You can create any UTC timestamp you want at any point in history > where it is defined. > > But you can only convert that UTC timestamp to a realtime_t (and > vice-versa) for timestamps where the conversion is defined. Then I suppose it wouldn't make sense to use your realtime_t format to store the events in calendaring / scheduling programs, since people often want to create scheduled events months or years in advance, or recurring on some regular basis (the third Saturday of every month at 7 PM) into the indefinite future. Usually such events are only "fixed" relative to local civil time in the place where the event is to take place, in which case they would shift relative to "real" TAI time with all changes to the local time, from leap seconds to changes in time zone boundaries and daylight saving rules. Other events, such as online events intended to be accessible to audiences around the world, would have times fixed to UTC, so they'd shift with leap seconds but not with local time rules. You'd then need to be able to store events in the program several different ways, fixed either to local time, UTC, or "real" TAI depending on which happens to be relevant to the particular event. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Steve Allen wrote: > > I also assert that this problem is being usefully addressed by the TC > TIMEZONE folks as they followup their work on creating RFCs 5545, > 5546, and the related protocols. I foresee that they will achieve a > working implementation for time zones. No, iCalendar is wrong because it requires early binding between locations and TZ offsets. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, South Rockall: Variable 4, becoming cyclonic, then southwesterly, 5 to 7, perhaps gale 8 later in south Rockall. Rough. Occasional rain. Moderate or good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Mon 2012-01-23T12:40:20 -0500, Keith Winstein hath writ:
> Steve Allen has opted for my #2 ("Correctly account for past leap
> seconds, and ignore yet-to-be-disseminated future leap seconds when
> converting EST/EDT/UTC-specified moments into a timestamp").
I assert that this is the same problem as ignoring yet-to-be-announced
changes in the zoneinfo files. The whims of the rotating earth bear
many resemblances to the whims of senators/presidentes/bureaucrats.
(The latter category cannot be suppressed by the ITU-R.)
I also assert that this problem is being usefully addressed by the TC
TIMEZONE folks as they followup their work on creating RFCs 5545,
5546, and the related protocols. I foresee that they will achieve a
working implementation for time zones.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855
1156 High StreetVoice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Mon, Jan 23, 2012 at 12:18 PM, Rob Seaman wrote:
> Whatever the design parameters of new APIs, e.g., floating-point or not, they
> will only succeed if the underlying conceptual model resembles the
> real-world. Steve Allen's concept of how such interfaces should interact
> with the system of timezones:
>
>
> http://www.cacr.caltech.edu/futureofutc/preprints/45_AAS_11-681_Allen.pdf
>
> is 1) written down and has references, and is 2) conformant with the
> real-world. On the other hand, the timezone assumptions underlying the
> "Draft Revision to ITU-R Recommendation TF.460-6" are neither. We need to
> revise the revision.
It's a good proposal, but I think the principal disagreement lies in
their choice of how to handle as-yet-unannounced intercalary seconds.
Steve Allen has opted for my #2 ("Correctly account for past leap
seconds, and ignore yet-to-be-disseminated future leap seconds when
converting EST/EDT/UTC-specified moments into a timestamp").
PHK has chosen #3 ("Correctly account for past leap seconds, and bomb
out with an error when converting future EST/EDT/UTC-specified
moments").
I think it's useful to make that disagreement explicit. I don't think
either choice #2 or #3 is more "conformant with the real world" than
the other.
Of course Steve's is nice because it doesn't require modifying
existing applications.
-Keith
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tony Finch wrote: > It is already commonplace. Well, no. The geographic center of California is about exactly 8 hours (120 degrees) west of Greenwich. Los Angeles is a couple of degrees East and San Francisco a similar distance West of this meridian. Even for California plate tectonics can be ignored, and PST will always remain naturally 8 hours from GMT. Both PST and GMT are stationary with respect to Universal Time. Historians or futurists, scientists or other long term planners can predict the relative activities in these two places on a given future calendar date, or proleptically backwards indefinitely even over periods that the length-of-day varies, precisely because it is days that are being counted. If Coordinated Universal Time is redefined, the foundation of this trembles. For a given UTC we would no longer even be able to predict the day it corresponds to, hence Steve Allen's comment: The effect of this proposal is not about clocks, but rather to disconnect the count of calendar days from the sun. It is - let's see, what's an appropriately technical term - "wacky" to encourage the timezone system to become unglued from the Earth. Both the ITU and US statements last week focus on "continuous time" as their continuing goal. This phrasing is troubling since as has been emphasized here UTC has always been precisely that: continuous. Putting that aside for the moment the question is how to reach a consensus that won't dump us right back in the current mess when the issue next comes up in 2015. Whatever the design parameters of new APIs, e.g., floating-point or not, they will only succeed if the underlying conceptual model resembles the real-world. Steve Allen's concept of how such interfaces should interact with the system of timezones: http://www.cacr.caltech.edu/futureofutc/preprints/45_AAS_11-681_Allen.pdf is 1) written down and has references, and is 2) conformant with the real-world. On the other hand, the timezone assumptions underlying the "Draft Revision to ITU-R Recommendation TF.460-6" are neither. We need to revise the revision. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012 Jan 23, at 01:45, Stephen Colebourne wrote: > The problem here is that the meaning to a human of a point defined in > the future solely in TAI seconds will change over time. The same is true for most future events in any time scale. The most evident example is the countdown for a launch. Determining the instant of launch requires coordination of many systems and people, each with its own clock and constraints, contributing to an overall need to stop or reset the master clock. This is a fact of the way real systems work, not a flaw in an API. It is unlikely that a general API for that sort of coordination can be constructed. It may be that a specific API could handle such things as civil time zone resets and serve as a good example for more complex scenarios. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Late binding, was Re: Lets get REAL about time.
Rob Seaman wrote: > > The plight will be writ large should the notion of timezone roulette be > implemented. In that case, over the centuries it will be similarly > unpredictable what timezone a particular country or province, state or > city observes - will observe - or did observe at some past moment > (without consulting some big book of timekeeping trivia). What is a > curiosity currently, the adjustment of a timezone, would become > commonplace and historians won't be able to "do operations" on UTC > timezone offsets as Zefram noted: It is already commonplace. The only sure way to schedule an event in the future is to specify a time and a place, and the time is to be understood as the commonly understood local time at that place. You also need a disambiguation flag to deal with changes to the local time scale, which should indicate the earlier or later of the possible times, so it can accommodate multi-stage DST or date line switches or other oddities not covered by a DST flag. In some cases you might need an abstruse notion of place, e.g. Han Xinjiang vs. Uighur Xinjiang. Calendaring software gets this wrong, and embeds the TZ offset in the data for a scheduled event too early. Warner said: > We need some kind of 'late binding' so that we can have time that's in > July 2012 when called from an app in Dec 2011 that shifts 1s once > the leap tables are updated... You achieve late binding by representing the target time in the target timescale. If you translate to some other timescale that has an unpredictable relation to the target timescale, you are causing problems for yourself. Poul-Henning said: > All other timescales, including UTC, will be derived from this floating > point value and represented in a suitable form for that timescale. All > other timescales, including UTC, will be derived from this floating > point value and represented in a suitable form for that timescale. Exactly. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fair Isle, Faeroes: Cyclonic, becoming southerly or southeasterly later, 5 to 7, occasionally gale 8 at first in north Faeroes, becoming variable 4 for a time. Moderate or rough, occasionally very rough at first in north Faeroes. Wintry showers. Good, occasionally poor. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 23 January 2012 08:05, Poul-Henning Kamp wrote:
> You can always compare them ("is date1 before, the same or after date2")
> but you cannot subtract them and get a precise time-difference, if they
> span a potential leap-second application.
>
> One obvious hack is to add a "double *error" argument which is
> set to the potential number of leapseconds between the two dates.
>
> But a similar problem appears as soon as we try to compare or subtract
> two timestamps in two different civil timescales, which includes
> UTC in my design: Som looney politician might change the timezone
> before we get there.
FWIW, JSR-310 handles that case, but its complex. We (currently) allow
the possibility to hold multiple versions of the time-zone rule data.
A ZonedDateTime (date and time with time-zone and offset) will
generally use the latest version of the tz rules data. But if that
make the datet-time invalid (because someone has updated the tz rule
data, user or politician), then the code will search the history of tz
rule data until it finds a rule set that does make the date-time
valid.
The leap-second case is also handles, by recording UTC as days and
nano-of-day (a flexible break in the notation that handles the
change), or by ignoring leaps via smoothing (UTC-SLS by default).
> It's the calculation of durations between timestamps on UTC in the future
> which is impossible, simply because they are undefined.
Not necessarily. The duration in days is well-defined, and thus a UTC
instant stored as days+nanos is well-defined for the future.
The problem here is that the meaning to a human of a point defined in
the future solely in TAI seconds will change over time. Thus TAI is of
most use solely as a clock defining now. The problem is that it is
easy for a user to get now, add 1000 * 86400 seconds to it and then
see the resulting time change over time. Thats why I (and others) see
TAI as unstable as a format for human timekeeping (useful for exact
duration based tasks, but those are relatively rare in my experience).
Reading the other mails, I think you can see where the primary concerns are:
- floating point - I and others are sceptical of that
- sole focus on TAI - for time geeks its correct and "real", but not
necessarily everyone thinks its "right"
- epoch choice - TAI, 1970 or some random choice
I think the first point looks wrong, but I'm not a kernel guy, so
thats who should guide you. A struct would be more Java-ish, but thats
probably as far as I can go.
I think you can mitigate the second objection by providing conversion
to UTC and a leapless 86400 non SI second scale in the core, and
separate from the breakdown to YMDHMS. ie YMDHMS is not the only
"broken down" form that users care about.
The third point is a detail.
Stephen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ] Fractional US civil time period representation is brittle
> Notice that I have not specified that the actual syscall must use FP, the > conversion from 64.64 to FP could, and probably should, happen in libc. That means somebody could implement this now with current POSIX kernel support and see how well it works. -- > My proposed API does not solve all imaginable problems relating to time, in > particular it does not solve the "programmer is clueless about time" > problem, but it does try to make it easier for programmers to do things > right, than for them to make mistakes. I think it would be a big help if the documentation had a section describing the not-so-obvious parts of time. Are they all associated with leap seconds? How about leap years? (a year from today gets interesting) Perhaps it should go in a separate man page listed in the SEE ALSO pages of time commands. --- Has anybody made a list of routines that take time as a parameter? sleep, usleep, select... --- >>Testing for equality of timestamps? > I would hope that using a FP format and mandate that for runtime you never > get two which are the same, should eliminate that hobby. They might be equal if generated on two different systems. Even if we only have one system, I'm not sure I want a simple concept like get-the-current-time to require a lock on multicpu or multicore systems. -- > You can create any UTC timestamp you want at any point in history where it > is defined. > But you can only convert that UTC timestamp to a realtime_t (and vice-versa) > for timestamps where the conversion is defined. > UTC is only defined approximately 6 months in advance, and that is an > interesting point for implementors of this API. I think a useful system needs a way to say "a year from now", or next Dec 25. -- > One of the problems right now with the 'right' database is that you have to > update it and already running programs don't notice this update since it > would be prohibitively expensive to do a stat call on each time operation. > Any clever ideas around this issue? 2 suggestions (we can debate the clever part): Poll once per day. Kick the program with a signal similar to what happens when log files get rotated, or piggyback on the same signal. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , "Tom Van Baak" writes:
>> So I can't do operations on UTC time stamps that are more than
>> 6 months in the future?
>
>The false assumption is that timestamps have infinite precision.
I pretty arbitrarily set the "default precision" to 0.1 second, based
on my reading of a number of technical documents for various system
designs in the transport sector.
NTP sets the precision at 128msec and is therefore technically "not
enough to ensure compliance" in some of these systems.
Only if we increase the default precision to <= 6sec, can we do 6
months in the future and be compliant with TF.460, as currently ratified.
>One solution is to somehow carry a measure of precision along with
>the timestamp. Note that comparing file mod times of files 10 or 20
>years ago does not require leap second tables.
As long as you only compare for order, in the same timescale, there
is no problem, provided you correctly tell if it is DST or not.
It's the calculation of durations between timestamps on UTC in
the future which is impossible, simply because they are undefined.
Adding error-bars throughout all calculations is not going to
fly with the 99% programmers, and if implemented correctly will
lead to a lot of fun in the "stupid pop-up-boxes" category.
>But where do you draw the line? The SI second was different 20
>years ago compared to today. Are you going to include TAI rate
>adjustment tables along with your new UTC library?
That one is TBD. It's only a matter of implementation, its not
important for the API.
>There are
>daily GPS time corrections available on the web; should those
>be included too? What good is a nanosecond timestamp if the
>server that generates it has microseconds of unknown error?
>I guess I object to the whole notion of mixing pico or attosecond
>precision with years or decades or centuries of range.
Except scientists increasingly want that resolution. Think CERN/LHC,
Gran Sasso, think timing of gamma ray bursts and supernovae.
Most users will probably continue with the ~0.05 second typical
precision of NTP.
The point here is to define _one_ API which does things right
inside the domain which might occur on a typical desk. Since
this domain includes both dates in early history of humanity
and benchmarking 4GHz processors, we get the big mantissa.
That obviously does not mean you can benchmark a 4GhHz processor
with full precision over the history of humanity.
As long as you stay inside one computer, you can use a local
timescale with a recent epoch ("start of program") and you
only need a small mantissa.
But as soon as you take timestamps across multiple computers,
be it for atomic physics or flight control, you need to reference
it to a common absolute epoch, and as time_t has shown, those
don't take very long to grow to 32 bits, thus outrunning 64
bits for your benchmarks.
112 bits is overkill, but there are no standardized datatypes
between 64 and 112.
>Another possible solution is to recall how denormalized floating
>point numbers work. There is an implicit trade-off here between
>precision and range. I wonder if the same concept could apply
>somehow to timestamps.
As I said earlier, one of the advantages of FP, is that you can
throw away precision in a structured fashion by using a smaller
FP type.
You could explot this, and never return more than a floats or
doubles worth of precision when doing subtractions, unless
you use the "CERN" functions.
The trouble with that is that no matter what you radix, there are
7 radix in timekeeping, the majority of them time-variant, so
the introduced error is going to look strange for normal people.
Strange as in: 2100-01-01 00:00:00 - 2012-01-01 00:00:00 = 87y11m27d
It's not a bad idea, but would you want to write the man-page to
explain this, so programmers and their users can understand the
error term ? Not me.
If we want 2100-01-01 - 2012-01-01 to return 88 years, there is
no way around doing the math in "broken down form".
My API forces that behaviour, by refusing to do that job.
>If you find yourself
>needing lots of bits, like more than 32 or 48 or 64, that is already
>a warning sign that you're doing something very wrong.
No, you are just running a numerical benchmark a few minutes long
between two computers with a standardized general purpose datatype
for timestamps on absolute timescales.
The requirement for 64+ bits does not come from any single user,
it comes from the data type being general purpose for all users.
My API allows us to have "only" two data types: The realtime_t
and "struct tm". You can only do away with realtime_t at great
computational expense.
>If you're writing a time library that won't work with an Arduino that
>too is a warning sign.
I fully agree with you, but this is an issue for later.
If we cannot make an API that works correctly when we have enough
CPU-power, we have no chance in hell on the Arduino.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
Re: [LEAPSECS] Lets get REAL about time.
In message , Mark Calabretta writes:
>At the current rate of leap second insertion, the worst-case scenario
>is that an as-yet unannounced leap second will occur in (slightly over)
>6 months.
Actually: Slightly _less_ than six months.
The on in june was announced on jan 5th.
>So effectively what is needed is a function to subtract two tm structs.
You can always compare them ("is date1 before, the same or after date2")
but you cannot subtract them and get a precise time-difference, if they
span a potential leap-second application.
One obvious hack is to add a "double *error" argument which is
set to the potential number of leapseconds between the two dates.
But a similar problem appears as soon as we try to compare or subtract
two timestamps in two different civil timescales, which includes
UTC in my design: Som looney politician might change the timezone
before we get there.
What the *error term should be set to in that case is anyones guess.
>Currently this is done by the user by converting the two structs to
>time_t and subtracting those. The implicit assumption is that that
>would now be done via realtime_t.
No, that will fail if we don't have a leapsecond table valid for
both timestamps.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
