Re: [LEAPSECS] Lets get REAL about time.
On 11 Feb 2012 at 14:26, Paul J. Ste. Marie wrote: > On 1/26/2012 4:42 PM, Hal Murray wrote: > > There are also months, but they are sufficiently non-uniform that nobody > > expects simple arithmetic conversions to work. > > Care to place money on that? A lot of financial stuff assumes a 360 day > year with 30 day months. Which shows that ignoring the realities of the date/time system on Earth to get math to come out easier dates back way before POSIX. -- == 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 1/26/2012 4:42 PM, Hal Murray wrote: There are also months, but they are sufficiently non-uniform that nobody expects simple arithmetic conversions to work. Care to place money on that? A lot of financial stuff assumes a 360 day year with 30 day months. -- --Paul A wholly owned subsidiary of: Sissy: DL R+W+B C 7 X L W C++ I++ T+ A E H++ S+ V-- F+ Q P B PA+ PL Aldebaran: DM Rt H 5 Y L- W+ C+ I++ T++ A+++ E H++ S+ V+ F++ Q+ P B++ PA- PL-- ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Stephen Colebourne said: > OK, I mean easy in computation, you mean easy as in well-defined result. Well, of course. Everything to do with dates is easy in computation once you've defined what results you're after. (Well, easy in that there's nothing strange that needs coding or corner cases to catch. It's not like doing a network protocol where there's all kinds of random events sticking their nose in.) -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 1/22/2012 7:42 AM, Clive D.W. Feather wrote:
#define timespecsub(vvp, uvp)\
((vvp)->tv_sec -= (uvp)->tv_sec, \
(vvp)->tv_nsec -= (uvp)->tv_nsec, \
((vvp)->tv_nsec< 0)\
? ((vvp)->tv_sec--, (vvp)->tv_nsec += 10) \
: (void) 0)
This has the advantage of being usable wherever a function can appear.
Not really. For example ×pecsub doesn't work. The do-while kludge
can at least protect the arguments, eg:
#define timespecsub(vvp1, uvp1) \
do {\
const struct timespec *vvp = vvp1; \
const struct timespec *uvp = uvp1; \
(vvp)->tv_sec -= (uvp)->tv_sec; \
(vvp)->tv_sec -= (uvp)->tv_sec; \
(vvp)->tv_sec -= (uvp)->tv_sec; \
(vvp)->tv_nsec -= (uvp)->tv_nsec; \
if ((vvp)->tv_nsec < 0) { \
(vvp)->tv_sec--;\
(vvp)->tv_nsec += 10; \
} \
} while (0)
and aside from not having an address otherwise behaves like a void function.
--
--Paul
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 27 January 2012 13:58, Clive D.W. Feather wrote: > Stephen Colebourne said: >>> Oh? When is a month from Monday coming? What day is 4 months after the last >>> day of next month? What about the antepenultimate day of next month? >>> Explain your working in each case. >> Each of those three examples requires the day-of-week, > > The first does, but only because I didn't phrase it as "When is a month > from 30th January?", which is what I meant. > >> The point of storing data in this form is that most queries of a date >> are for year, month and day-of-month. Similarly, most sets/adds, like >> 2012-01-31 + 1month require the year, month and day-of-month. In the >> format above, those calculations are easy. > > Okay, all of those three (as amended in the first case) are of that form: > > 2012-01-30 + 1 month > 2012-02-29 + 4 months > 2012-02-27 + 4 months > > and let me add: > > 2011-02-28 + 1 year OK, I mean easy in computation, you mean easy as in well-defined result. JSR-310 currently has a resolver plugin that you can specify to control the result. http://threeten.sourceforge.net/apidocs-2011-01-07/javax/time/calendar/DateResolvers.html The default is previous-valid: 2012-01-30 + 1 month = 2012-02-29 2012-02-29 + 4 months = 2012-06-29 2012-02-27 + 4 months = 2012-06-27 2012-02-29 + 1 year = 2013-02-28 2011-02-28 + 1 year = 2012-02-28 Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tony Finch said: > The usual way to deal with logic of this kind is to be explicit about > whether you are counting from the start or the end of the month. I don't > know if there is consensus on whether day-of-month overflows should > saturate or carry... Indeed. Which is why it isn't easy, contrary to the previous statement. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Clive D.W. Feather wrote: > > Okay, all of those three (as amended in the first case) are of that form: > > 2012-01-30 + 1 month > 2012-02-29 + 4 months > 2012-02-27 + 4 months > > and let me add: > > 2011-02-28 + 1 year The usual way to deal with logic of this kind is to be explicit about whether you are counting from the start or the end of the month. I don't know if there is consensus on whether day-of-month overflows should saturate or carry... Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: Variable becoming southerly 3 or 4, increasing 5 to 7. Rough or very rough. Wintry showers then rain. Moderate or good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Stephen Colebourne said: >> Oh? When is a month from Monday coming? What day is 4 months after the last >> day of next month? What about the antepenultimate day of next month? >> Explain your working in each case. > Each of those three examples requires the day-of-week, The first does, but only because I didn't phrase it as "When is a month from 30th January?", which is what I meant. > The point of storing data in this form is that most queries of a date > are for year, month and day-of-month. Similarly, most sets/adds, like > 2012-01-31 + 1month require the year, month and day-of-month. In the > format above, those calculations are easy. Okay, all of those three (as amended in the first case) are of that form: 2012-01-30 + 1 month 2012-02-29 + 4 months 2012-02-27 + 4 months and let me add: 2011-02-28 + 1 year -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 27 January 2012 10:50, Clive D.W. Feather wrote: > Stephen Colebourne said: >> Interestingly, in JSR-310 I may end up representing a date as a packed >> form of day-of-month (5 bits) and epoch-months (59 bits). Month >> calculations are then easy. > > Oh? When is a month from Monday coming? What day is 4 months after the last > day of next month? What about the antepenultimate day of next month? > Explain your working in each case. Each of those three examples requires the day-of-week, thus can't be calculated from month alone (it needs the whole date). Calculating the day-of-week involves calculating a day-count, and then going from there. The point of storing data in this form is that most queries of a date are for year, month and day-of-month. Similarly, most sets/adds, like 2012-01-31 + 1month require the year, month and day-of-month. In the format above, those calculations are easy. The trade off is that some other calculations are harder. Design is always about trade-offs. Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Stephen Colebourne said: > Interestingly, in JSR-310 I may end up representing a date as a packed > form of day-of-month (5 bits) and epoch-months (59 bits). Month > calculations are then easy. Oh? When is a month from Monday coming? What day is 4 months after the last day of next month? What about the antepenultimate day of next month? Explain your working in each case. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 27 January 2012 00:42, Hal Murray wrote: > I think the key idea is that there are several units of time and things like > leap seconds, time zones, and leap years make conversion between them far > from simple. > > We want to work with time in units of: > SI seconds > Days > Years > kilo- and mega- years > > Picking an API that focuses on one makes it hard to do things in the others. Agreed, but I'd note that you missed out 1/86400th of a day. Many developers will write code that does simple maths on a seconds count. They do this because of developer mentality (too simple to use a library, too slow to use a library, NIH...). If that kind of developer is given only SI seconds, they will actually make more errors than if they are given 1/86400th-econds. I understand that the above paragraph really frustrates the experts, time-nuts and scientists. But I strongly believe that it is representative of what the human developers are doing and will do. 86400 per day and simple maths are *very* ingrained. Thats why I still think that the SI-second should be renamed (scientists and experts can handle that), leaving the second as a number which divides the day into 86400 parts (probably with some being rubber, and others not rubber). > There are also months, but they are sufficiently non-uniform that nobody > expects simple arithmetic conversions to work. Interestingly, in JSR-310 I may end up representing a date as a packed form of day-of-month (5 bits) and epoch-months (59 bits). Month calculations are then easy. > If we are going to make any progress in this area, I think we have to come up > a collection of APIs that cover all the needs and a good description of how > to decide which one to use, and why. There are undoubtably multiple levels to the APIs needed. JSR-310 has levels too. PHK is currently proposing the lowest level, a TAI seconds clock. I think that is valuable, but I fear that only supplying the conversion to struct tm is insufficient for the rest of the needs, and will lead to abuse of the new API and probably more bugs than today. Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
> Indeed, but that is a different task from what I am trying to specify here. > I'm only trying to do the API for dealing with present and past time and > timeintervals past us, in a computationally efficient manner. > There's a lot of business programming for which days are far more important > than seconds, but in those cases (interest, book releases, etc), it's very > much local legal time that matters, not a continuous timescale. Correct > and current daylight saving time transitions are more important than leap > seconds and milliseconds in those cases. I think the key idea is that there are several units of time and things like leap seconds, time zones, and leap years make conversion between them far from simple. We want to work with time in units of: SI seconds Days Years kilo- and mega- years Picking an API that focuses on one makes it hard to do things in the others. There are also months, but they are sufficiently non-uniform that nobody expects simple arithmetic conversions to work. If we are going to make any progress in this area, I think we have to come up a collection of APIs that cover all the needs and a good description of how to decide which one to use, and why. - It might be possible to use seconds to describe times in the future if you also carried along some sort of fuzziness range. The idea is to be able to say: X seconds from now, but I only need it to the day so I don't care about leap seconds or DST. (But that breaks when your country jumps across the international date line.) It might help if routines like localtime and gmtime had another parameter to tell them the round-off granularity: minute, hour, day, month, year, century... -- 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.
On 1/21/2012 4:44 AM, Poul-Henning Kamp wrote: I think it is important that the unit of the representation is a second rather than a day, simply because most of the stuff computers do are in the second domain, not in the day domain. (See code example above) There's a lot of business programming for which days are far more important than seconds, but in those cases (interest, book releases, etc), it's very much local legal time that matters, not a continuous timescale. Correct and current daylight saving time transitions are more important than leap seconds and milliseconds in those cases. The basic problem is that no one knows exactly how long from now it will be until 2026-July-28 09:00:00 US/Eastern. You could have a daylight saving time definition change, the US might shift to a single time zone, Congress might rearrange the months, etc. Nevertheless, if that date's in a contract somewhere, it's the definition when it arrives that will matter, not when we think it will arrive today. -- --Paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tony Finch wrote: > Have there really been that many? Any refs to ones other than Markus's and > Google's? There is also my UTR scheme: http://ifctfvax.Harhan.ORG/timekeeping/draft-utrspec.txt http://ifctfvax.Harhan.ORG/timekeeping/draft-utrdef.txt MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tony Finch wrote: > There's also the railway clock genre, where each clock's second hand ticks or > sweeps slightly fast, and the clock waits at the top of the minute for a > synchronization pulse. Handles leap seconds easily, if the master clock does > :-) > > http://www.youtube.com/watch?v=IvIvKiDWDks Interesting how many variations we're finding. What you describe is similar to cadenced exposure modes: http://adass.org/adass/proceedings/adass96/reprints/seamanr2.pdf An alarm is set for a particular clock tick (here in a heliocentric timescale) and this acts as a governor on an otherwise undisciplined sequence of exposures, perhaps extending over multiple sessions. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Mark Calabretta wrote: > > There are two basic types of analogue clock display. One where the > second hand steps around the dial from second to second (thus > disawowing sub-second timekeeping), and the other where it moves > smoothly and continuously. It is interesting to contemplate how a > leap second would appear on each were it to be implemented. There's also the railway clock genre, where each clock's second hand ticks or sweeps slightly fast, and the clock waits at the top of the minute for a synchronization pulse. Handles leap seconds easily, if the master clock does :-) http://www.youtube.com/watch?v=IvIvKiDWDks Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: Southeasterly 6 to gale 8, perhaps severe gale 9 later in Fisher. Moderate or rough, occasionally very rough later. Rain. Moderate or good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tom Van Baak wrote: > > And again, this is an example of what I meant by a collection of best > practices documents. I think it is much better for the community to > document the idea of smoothed leap seconds and then describe the dozen > ways it has been proposed or actually already implemented. Have there really been that many? Any refs to ones other than Markus's and Google's? Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Southeasterly gale 8 to storm 10, perhaps violent storm 11 later in Viking. High, occasionally very high. Rain. Moderate. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message <5db9794a-4952-4a3b-98af-65e9573b2...@develooper.com>, =?utf-8?Q?Ask _Bj=C3=B8rn_Hansen?= writes: >This is not a general date and time handling API; just a timekeeping one. Correct, people seem to be confused about this, so let me explain: We need an API which tells you what time *it is*, for instance for recording and ordering transactions in a database or to *measure* time intervals. We also need to be able to coordinate activities between loosely coupled computers, for instance robots in a factory, and that mandates that we have to be able to look into the future too. This API needs to be fast, and it needs to work without consulting databases, files or servers. That's what my API proposal is about. By basing the timescale on accumulated SI seconds, you can predict the occurence of events in the future, as long as you express the time until they happen, in units of seconds. But you can not express the time until future events happen in minutes, hours, days, weeks, months or years, because all of those have varaiable lengths, measured in seconds. For that another API is needed, one that understands timezones, DST and leap days and leap-seconds. That "calendrial" API I will leave to others to work out. I've probably added to the confusion by specifying the linkage between the two APIs, but since this discussion is fundamentally about how computers deal with leap-seconds, that was a very important aspect of the API to cover. Apart from this confusion, I have yet to see any serious objections to my proposal ? -- 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
Re: [LEAPSECS] Lets get REAL about time.
On Jan 24, 2012 Mark Calabretta wrote:
>>> int tmdiff(const struct tm *tm1, const struct tm *tm2, double *diff);
>>>
>>> Return the time interval, *tm2 - *tm1, in SI seconds.
>>
>> ENOCANDO
>
> As a further example of the need to handle future dates, consider
> that of producing Gantt charts and the like for project management.
> These do require a time interval and not just the representation
> and ordering of future events.
They need a different "deal with time" API with features appropriate for that.
(Maybe using similar data structures, but likely not at all).
> I don't think you have much hope of getting your realtime_t proposal
> accepted by the wider unix community if ENOCANDO is the best it can
> do for such.
As I read the proposal it was just for a low-level "what time is it now" API
that kernels can provide and basic timekeeping things ("infrastructure") can
use. Since the proposal is to keep the system time in a different (but simpler
and more basic) time scale than people usually use, it also has functions for
converting to other time scales for current time and past dates (showing file
stat information, for example). On an operating system level you rarely need
future dates in this format.
This is not a general date and time handling API; just a timekeeping one.
Ask
--
http://askask.com/
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
I vigorously advocate only the general idea of rubberization. The exact mode of rubberization is up to each individual implementor in practice. This sounds good to me too. Alice and Bob may choose two different rubberization schemes, but the magnitude of the difference between their clock readings can't exceed 1 s at any point. MS And again, this is an example of what I meant by a collection of best practices documents. I think it is much better for the community to document the idea of smoothed leap seconds and then describe the dozen ways it has been proposed or actually already implemented. That way designers can learn from other examples and implement something tailored to their particular application. The one-size-shall-fit-all approach of the existing UTC-SLS reminds me of Gates, DOS, and 640K. Markus, if you're lurking, could you at least rename your proposal to UTC-SLS-1000? /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Or it could move from 00 back to 59... The way wristwatch stepper motor are designed you can't go counter-clockwise. So you either stay at 59 or 00 for 2 seconds, or like my earlier reply, for those continuous sweep motors, you could probably alter +/- the rate by a factor of two or 1.5 or 1.25 or 1.125, depending on the motor. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tom Van Baak wrote: > Except it doesn't work for binary systems. 32.768 Hz watches > would prefer steps of 1/1024 s. UTS was a fine idea until it > was so overly specified. Since you are already dealing with > timekeepers that do not care so much about sub-second > accuracy a smoothed leap second proposal should allow > flexibility. I vigorously advocate only the general idea of rubberization. The exact mode of rubberization is up to each individual implementor in practice. Alice and Bob may choose two different rubberization schemes, but the magnitude of the difference between their clock readings can't exceed 1 s at any point. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
There are two basic types of analogue clock display. One where the second hand steps around the dial from second to second (thus disawowing sub-second timekeeping), and the other where it moves smoothly and continuously. It is interesting to contemplate how a leap second would appear on each were it to be implemented. In the second case, it might be possible to speed up or slow down the second hand to cover both negative or positive leap seconds; essentially a form of SLS. Whether one to starts the speed change 1 second before the hour or 1000 seconds before the hour or N seconds before the hour is debatable. For a wristwatch probably one second is best; that is, get the leap over with as soon as possible. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Both wrong. The right way is UTC-SLS. Except it doesn't work for binary systems. 32.768 Hz watches would prefer steps of 1/1024 s. UTS was a fine idea until it was so overly specified. Since you are already dealing with timekeepers that do not care so much about sub-second accuracy a smoothed leap second proposal should allow flexibility. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Tue 2012/01/24 18:14:26 PDT, Warner Losh wrote in a message to: Leap Second Discussion List >> TF460-6 specifies that time during a leap second be represented as, >> for example, 23:59:60.7, which suggests to me that the second hand >> should move past 60 to "61". > >But then it would be in the wrong minute. True - if you took a photo of the clock at 23:59:60.7 then you wouldn't be able to decide from that alone that the time wasn't 00:00:00.7 (assuming that the minutes and hour hand also move smoothly). So you'd have to be watching the clock at the time the leap second occurred. Regards, Mark ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Jan 24, 2012, at 4:51 PM, Mark Calabretta wrote: > > On Tue 2012/01/24 16:23:17 PDT, Warner Losh wrote > in a message to: Leap Second Discussion List > >>> In the latter, the second hand would move continuously past 60 to 01 >>> second and immediately flick back to 60, thus making it possible to >>> reckon time during a leap second. >> >> Or it could move from 00 back to 59... >> >> And the number of choices here is illustrative of the implementation >> details elsewhere :) > > TF460-6 specifies that time during a leap second be represented as, > for example, 23:59:60.7, which suggests to me that the second hand > should move past 60 to "61". But then it would be in the wrong minute. What's the right answer: both. The standard is silent on the issue since there is no '60' on the clock. One can get the minute and hour wrong by repeating the first 6-degrees of the dial and have the 'wrap' be like you suggest. One can get the minute and hour right, but with a less "modulus"ly beautiful 60 - 00. There's no standard for mapping a non-uniform radix onto a uniform-radix device. Implementations on POSIX time_t based systems suffer similar ambiguity. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Mark Calabretta wrote: > In the former, on reaching 60, the second hand would stay there for 2 > seconds thus making it impossible to track time during a leap second. > > In the latter, the second hand would move continuously past 60 to 01 > second and immediately flick back to 60, thus making it possible to > reckon time during a leap second. Both wrong. The right way is UTC-SLS. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Tue 2012/01/24 16:23:17 PDT, Warner Losh wrote in a message to: Leap Second Discussion List >> In the latter, the second hand would move continuously past 60 to 01 >> second and immediately flick back to 60, thus making it possible to >> reckon time during a leap second. > >Or it could move from 00 back to 59... > >And the number of choices here is illustrative of the implementation >details elsewhere :) TF460-6 specifies that time during a leap second be represented as, for example, 23:59:60.7, which suggests to me that the second hand should move past 60 to "61". Regards, Mark ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Tue 2012/01/24 08:22:41 -, "Poul-Henning Kamp" wrote in a message to: Mark Calabretta and copied to: Leap Second Discussion List >> int tmdiff(const struct tm *tm1, const struct tm *tm2, double *diff); >> >> Return the time interval, *tm2 - *tm1, in SI seconds. > >ENOCANDO As a further example of the need to handle future dates, consider that of producing Gantt charts and the like for project management. These do require a time interval and not just the representation and ordering of future events. I don't think you have much hope of getting your realtime_t proposal accepted by the wider unix community if ENOCANDO is the best it can do for such. >Ohh, and btw: That function is a hell to write and it will never >qualify as efficient... It's no more complicated than tm_realtime(), and no slower than two invokations of it. Regards, Mark ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
We should offer a prize when a new talking point is raised that hasn't appeared here before. I don't remember this one :-) Very interesting. What about the other hands? The watch on my wrist is of the stepping, not sweeping, kind. But the other hands appear to move at a continuous pace. Implementing a leap second by this analysis would require the minute and hour hands to execute a less dramatic version of the flick maneuver (or a lien on the requirement and just accept the tiny angular display error). For the non-astronomers here, note that the middle of the night can be the worst possible time to implement the little dance Steve describes. Rob -- On Jan 24, 2012, at 4:01 PM, Mark Calabretta wrote: > > On Tue 2012/01/24 07:18:36 -0800, Steve Allen wrote > in a message to: Leap Second Discussion List > >> The ones with WWVB >> receivers in them do a little dance every night when nobody is >> watching and the signal is strong, and that dance looks a lot >> like the handling of a leap second. > > There are two basic types of analogue clock display. One where the > second hand steps around the dial from second to second (thus > disawowing sub-second timekeeping), and the other where it moves > smoothly and continuously. It is interesting to contemplate how a > leap second would appear on each were it to be implemented. > > In the former, on reaching 60, the second hand would stay there for 2 > seconds thus making it impossible to track time during a leap second. > > In the latter, the second hand would move continuously past 60 to 01 > second and immediately flick back to 60, thus making it possible to > reckon time during a leap second. > > Regards, Mark ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Jan 24, 2012, at 4:01 PM, Mark Calabretta wrote: > > On Tue 2012/01/24 07:18:36 -0800, Steve Allen wrote > in a message to: Leap Second Discussion List > >> The ones with WWVB >> receivers in them do a little dance every night when nobody is >> watching and the signal is strong, and that dance looks a lot >> like the handling of a leap second. > > There are two basic types of analogue clock display. One where the > second hand steps around the dial from second to second (thus > disawowing sub-second timekeeping), and the other where it moves > smoothly and continuously. It is interesting to contemplate how a > leap second would appear on each were it to be implemented. > > In the former, on reaching 60, the second hand would stay there for 2 > seconds thus making it impossible to track time during a leap second. Or it could "stutter" to the next second so you'd at least know a second was ticking.. > In the latter, the second hand would move continuously past 60 to 01 > second and immediately flick back to 60, thus making it possible to > reckon time during a leap second. Or it could move from 00 back to 59... And the number of choices here is illustrative of the implementation details elsewhere :) Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Tue 2012/01/24 07:18:36 -0800, Steve Allen wrote in a message to: Leap Second Discussion List >The ones with WWVB >receivers in them do a little dance every night when nobody is >watching and the signal is strong, and that dance looks a lot >like the handling of a leap second. There are two basic types of analogue clock display. One where the second hand steps around the dial from second to second (thus disawowing sub-second timekeeping), and the other where it moves smoothly and continuously. It is interesting to contemplate how a leap second would appear on each were it to be implemented. In the former, on reaching 60, the second hand would stay there for 2 seconds thus making it impossible to track time during a leap second. In the latter, the second hand would move continuously past 60 to 01 second and immediately flick back to 60, thus making it possible to reckon time during a leap second. Regards, Mark ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Rob Seaman wrote: > > 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 [...] I agree with Clive's response to this but I feel the need to unpack it a bit more. You're mixing up at least five timescales with very different characteristics here, and expecting their relations to remain predictable thousands of years into the future. You are also using rather imprecise terminology which makes the tangle particularly knotty: by "GMT" I'm not sure if you mean UTC or UT1 or British time in winter or Microsoft-style British time at any time of year. Anyway, you seem to be talking about standard time zones (not local mean solar time, say) but you are ignoring the fact that standard time isn't used for more than half of the year, and a place might choose to use a time that's very different from their standard time. (And change their mind back, as Britain has done a couple of times.) Over the next ten years it is very possible for the time difference between California and Britain to be anything from 7h (California on PDT, Britain on WET) to 10h (California on PST, Britain on CEST). So even in the near future it is the case that planners cannot predict the relative activities in these two places. Having said that, in the far future it is likely that British time will still be roughly centred on UT1 and California time will be roughly centred on UT1-8h, plus or minus a couple of hours each way. That is, the timezone system will be used to keep them stationary wrt universal time, though with a fair amount of slop - but that slop is the same as the present-day slop. So the foundation does not tremble. You only think it trembles because you are falsely assuming that the diverging difference between TAI and UT1 will lead to people getting up in the night or miscounting the days of their calendars. Yes you won't be able to predict the relation between atomic time and solar time - that is of course physically impossible. Yes you won't be able to predict what the politicians will decree about time zone offsets and daylight saving - and that is also necessarily impossible. But neither of these impossibilities imply that local civil time will diverge from local solar time. A somewhat irrelevant aside: even if you are talking about local mean solar time, over the timescales you are worrying about it is not the case that 120 degrees equals 8h (28800 SI seconds) because tidal slowdown is making it longer. And earthquakes and plate tectonics will add further disturbances to the time difference between California and Britain even if you use UT1 seconds. But this is all milliseconds rather than hours... Tony. -- f.anthony.n.finchhttp://dotat.at/ Dover, Wight, Portland, Plymouth, North Biscay: Westerly or southwesterly 4 or 5, increasing 6 at times, increasing 6 or 7 later in Plymouth and north Biscay. Mainly moderate. Rain. Good, occasionally poor. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
My analog clocks with just quartz crystals don't keep time to within a second over the relevant interval. The ones with WWVB receivers in them do a little dance every night when nobody is watching and the signal is strong, and that dance looks a lot like the handling of a leap second. Yeah, it's very cool. If you use a magnetic or acoustic pick-up you can monitor those watches. See: http://leapsecond.com/pages/Junghans/ It is lucky for wristwatches that they are leap second immune by virtue of their inherent inaccuracy. Too bad PC's can't be treated the same way! /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012 Jan 24, at 07:12, Tom Van Baak wrote: > I would like to agree with you, but can't. The dial is shared by > the seconds, minutes, and hours hand so your proposal isn't > going to work. Open an analog clock and have a look. My analog clocks with just quartz crystals don't keep time to within a second over the relevant interval. The ones with WWVB receivers in them do a little dance every night when nobody is watching and the signal is strong, and that dance looks a lot like the handling of a leap second. -- 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] Lets get REAL about time.
If leap seconds were predictable (say they were exactly one every 18 months for the next century) it would be perfectly practical to build an analogue clock that had 61 divisions on the dial carrying the second hand, and which jumped the 60 position in most minutes. I would like to agree with you, but can't. The dial is shared by the seconds, minutes, and hours hand so your proposal isn't going to work. Open an analog clock and have a look. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Keith Winstein said: > Hmm, in practice I think the plan to simply fail with an error is > going to be a non-starter. Plenty of applications need to record dates > more than six months in the future; e.g. in a calendar program, the > user will want to schedule a meeting for August 1, 2012, from 9 a.m. > EDT to 10 a.m. EDT. Actually, let's suppose it was March, not August. The user probably wants to schedule a meeting for 26th March 2013, 09:00 ET to 10:00 ET. Now the user doesn't care at this point whether ET is EST or EDT. If the changeover date changes between now and then, they want the appointment to remain ET. > The program will want to do all the normal things > -- calculate the duration of the meeting, how far in the future it is > (so it can put it in sorted order along with the other events of that > day), etc. Right. And they want all the ET events sorted by ET, irrespective of whether "daylight saving time" is in effect or not. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Rob Seaman said: >> 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. Wrong. Yes, the "mean solar time for 120 west" will always remain naturally 8 hours from the "mean solar time for 0 east/west". But it could well be that neither of those is the civil time for anywhere. Consider China. It decided that the civil convenience of keeping the whole country on one time zone was more important that the civil convenience of having the fictional mean sun be at the zenith at 12:00 everywhere. So even though it stretches from 73 east to 135 east, it uses the time zone of 120 east throughout. It is quite possible that a future USA government might decide that this same balance of civil conveniences has swung, and decide to move the whole country to the time zone of 90 west throughout. At that point PST will be, in essence, what you now call CST, and more to the point will be only 6 hours from GMT. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Rob Seaman wrote: > > 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. The way to deal with multi-location metings is to choose a primary location, then it it obvious what will happen when TZ rules change. Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames: Southwest, backing southeast, 4 or 5, occasionally 6 later. Slight or moderate. Rain. Good, occasionally poor. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Michael Sokolov said: > What people like PHK fail to grasp is that a whole ton of applications > absolutely DO NOT CARE how many Cs-133 transitions happen to occur in > a given *civil* time interval, all they care about is a bijective > mapping between their timestamps and *official civil time*. Agreed. > Each (micro-)nation should indicate its official time with an analog > clock (i.e., one with rotating hands, not digital) on the wall of a > government building specifically to drive the point home that notations > like 23:59:60 are not acceptable. This non-scalar notation is the > real fundamental problem with UTC in my eyes, Total nonsense. (Nitpick: it's not non-scalar, it's non-uniform.) If that were a valid argument, then we wouldn't have different numbers of days in the month because you couldn't have a day-of-month hand on a clock. Yet clockmakers and the general public seem to have coped. If leap seconds were predictable (say they were exactly one every 18 months for the next century) it would be perfectly practical to build an analogue clock that had 61 divisions on the dial carrying the second hand, and which jumped the 60 position in most minutes. > i.e., they should not pretend to have any relation to time-as-in-physics > and should merely represents particular points in the course of > "analog" civil time, i.e., particular angular positions of the > rotating hands of the official clock on the wall of a government > building. An indication that Mary Q. Public's subscription expires at > 2022-07-25T19:41:42 UT1 is perfectly precise and unambiguous > regardless of how many leap seconds occur between now and then. Except: (1) the notation 2022-07-25T19:41:42 UTC is equally precise and unambiguous when it happens; (2) since you don't know how much the earth will slow down in the next 10.5 years, you can't (easily, if at all) build a clock that will rotate the correct number of times; (3) neither UT1 nor UTC is civil time (though civil time may be based on one or the other). > On the other hand, the *civil* timekeeping requirements can be very > stringent. The example of expiration of subscriptions that Keith has > brought up is a very good one: I like the idea of the moment of > subscription expiration far in the future being defined very precisely > *in relation to official civil time*, which for the Republic of New > Poseidia is currently UT1. But in the real world it *isn't* that predictable. Let's take that subscription you mention. Under English law that time - without the "UT1" tag - would be interpreted as BST, since under the Summer Time Act all times in July are to be interpreted as BST unless specifically mentioned. Right now BST means GMT+1 (for some meaning of GMT I'm not going to debate right now). But perhaps Labour come back into power in 2015 and decide to move us all to the same time as France and Germany. At which point BST will mean GMT+2. So never mind the 7 or 8 leap seconds - we can't even predict duration to within an hour. And that, I think, matches Tony Finch's point: for many things you don't care about the interval, you care about the end time in the *relevant* time zone. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , Mark Calabretta writes:
>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.
ENOCANDO
At best you can return it as a "struct tm" recording the expected
difference.
For instance:
{2100-01-01 00:00:00Z} - {2012-01-01 00:00:00Z} = {88y}
... but we don't know how many seconds.
Ohh, and btw: That function is a hell to write and it will never
qualify as efficient...
--
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
Re: [LEAPSECS] Lets get REAL about time.
In message <4f1e04b4.972.1d564...@dan.tobias.name>, "Daniel R. Tobias" writes: >On 22 Jan 2012 at 0:09, Poul-Henning Kamp wrote: >> 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, You are right. Such "out of domain" usage of time_t is a major part of the trouble with the current handling of leap-seconds. >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. Indeed, but that is a different task from what I am trying to specify here. I'm only trying to do the API for dealing with present and past time and timeintervals past us, in a computationally efficient manner. -- 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
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] 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] 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
Re: [LEAPSECS] Lets get REAL about time.
On Jan 22, 2012, at 11:16 PM, Rob Seaman wrote:
> Warner Losh wrote:
>
>> So I can't do operations on UTC time stamps that are more than 6 months in
>> the future?
>
> It depends what operations, and what a timestamp is deemed to mean.
> Currently UTC approximates UT; it is stationary wrt time-of-day. Myriads of
> human activities are diurnal and time-of-day is the pertinent timescale.
> Measuring future or past intervals in SI-seconds is beside the point for
> these use cases, an exercise in fitting a square peg in a round hole.
UTC is a backward looking timescale. When I say I want something at 10:32:00
am UTC on July 5th, 2013 I want that. I don't want an approximation to UT or
anything else. I want that. By converting to a timescale without leap seconds
still has the problems of leap seconds.
> 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:
Historically, we'll know. We have the Olson database. In the future we cannot
know, because UTC has nothing to do with what time-zone a particular hunk of
land will be using in the future. That's a political decision, and always has
been. We also don't know what the offset between UT in Basel Germany their
town clock was set to on June 18th 1652. There was no UTC then, and I'm not
aware of daily records that are extant for such conversions... This doesn't
seem to bother most historians. The bigger problem is knowing if Basel was in
the Catholic part of Germany or the Protestant to know what date was on the
calendars that day (or which day gregorian corresponds to the day that had that
date on their calendars).
>>> Other direction. Paris's UT+1h would become TI+1h, then TI+0h, TI-1h,
>>> TI-2h, and so on. ("TI" meaning the no-leap-seconds time scale that
>>> succeeds UT in common use.)
>
> Even the direction of drift will be a matter of debate as demonstrated on
> this list.
Lots of things are debated on this list, but that doesn't mean they are in
question... :)
Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
libc will need an updated table of leap-seconds to give you UTC, and if you hand it a timestamp that is more than some set delta-T from the last entry in the leapsecond table, it will return E2BIG rather than give you a potentially wrong timestamp. So I can't do operations on UTC time stamps that are more than 6 months in the future? If true, it's a bogus design. The false assumption is that timestamps have infinite precision. We don't place that constraint on any other physical quantity. Go ahead and allow UTC into the future; but just adjust the precision accordingly. Where are the error bars in your measurements? 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. 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. 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? 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. Seconds and days and years are three different clocks. 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. If you're writing a time library that won't work with an Arduino that too is a warning sign. Don't forget that Unix was the Arduino of its day. So if you want to improve timekeeping for the future then start with the hardware and software and the kids who will inherit the future. I guess that's my 2 cents worth. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Warner Losh wrote:
> So I can't do operations on UTC time stamps that are more than 6 months in
> the future?
It depends what operations, and what a timestamp is deemed to mean. Currently
UTC approximates UT; it is stationary wrt time-of-day. Myriads of human
activities are diurnal and time-of-day is the pertinent timescale. Measuring
future or past intervals in SI-seconds is beside the point for these use cases,
an exercise in fitting a square peg in a round hole.
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:
>> Other direction. Paris's UT+1h would become TI+1h, then TI+0h, TI-1h,
>> TI-2h, and so on. ("TI" meaning the no-leap-seconds time scale that
>> succeeds UT in common use.)
Even the direction of drift will be a matter of debate as demonstrated on this
list.
Rob
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Jan 21, 2012, at 4:20 PM, Keith Winstein wrote: > On Sat, Jan 21, 2012 at 7:44 AM, Poul-Henning Kamp > wrote: > >> libc will need an updated table of leap-seconds to give you UTC, >> and if you hand it a timestamp that is more than some set delta-T >> from the last entry in the leapsecond table, it will return E2BIG >> rather than give you a potentially wrong timestamp. > > My concern is with this part of the proposal. > > You are saying that if the time given is more than six months in the > future, realtime_tm() will simply return an error and will not be able > to produce a human-readable timestamp (whether in UTC, EST, EDT, CET, > BST, etc.). > > Isn't this a problem? Plenty of applications try to display dates and > times (both in the local time zone and in UTC) that are more than six > months in the future. E.g. calendar programs, the at tool, astronomy > programs, billing software, accounting software, Web browsers (e.g. > showing cookie expirations in human-readable form). 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... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Jan 21, 2012, at 6:44 AM, Poul-Henning Kamp wrote: >> My question, though: if the offset is in TAI, and you have to >> support "UTC", how do you get your leap second tables to do the >> conversion? > > The reason for TAI is that way the kernel will not need the leapseconds > only userland will. > > libc will need an updated table of leap-seconds to give you UTC, > and if you hand it a timestamp that is more than some set delta-T > from the last entry in the leapsecond table, it will return E2BIG > rather than give you a potentially wrong timestamp. So I can't do operations on UTC time stamps that are more than 6 months in the future? > NTP can transfer the leap-second table these days, and all sorts > of software update mechanisms could as well. 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? Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Sun 2012/01/22 19:04:05 -, "Poul-Henning Kamp" wrote in a message to: Keith Winstein and copied to: Leap Second Discussion List >> Plenty of applications need to record dates >>more than six months in the future; > >They can trivially do that, but they have to do it in a format >that can represent the time. > >"struct tm" can do that, (if we add frational seconds to it as >I proposed) I agree. It is the only way that a future UTC or localtime can be stored. >But time_t and realtime_t can not, because they are scalar and >the scalar number of seconds between any epoch and UTC timestamp >more than 6 months out in the future, is undefined. 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. 1 second in 6 months is one part in 16,000,000 which, for most (all?) civil timekeeping purposes, is well enough defined to compute a time interval of sufficient accuracy. In any case, as Keith implied, often only the intended order of future events is important. So effectively what is needed is a function to subtract two tm structs. 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. However, that need not be so. All that is required is for users to be provided with a convenient way to subtract two tm structs. Regards, Mark ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , Keith Winstein writes: >>>Isn't this a problem? >> >> If it is, it's a not problem with the API, but with the way >> leap-seconds are defined. > >Hmm, in practice I think the plan to simply fail with an error is >going to be a non-starter. Gee, I wonder where all these people got the crazy idea that leap seconds could be a problem for computers :-) > Plenty of applications need to record dates >more than six months in the future; They can trivially do that, but they have to do it in a format that can represent the time. "struct tm" can do that, (if we add frational seconds to it as I proposed) But time_t and realtime_t can not, because they are scalar and the scalar number of seconds between any epoch and UTC timestamp more than 6 months out in the future, is undefined. >Perhaps you envision a whole other, separate API for representing and >validating EDT (and other civil time, and UTC) timestamps That's what "struct tm" is for, it records the timestamp on "broken down" format, including the timezone. >The notion that "the API" can do nothing more than report an error >message is not quite right. There are some alternatives: > >1) Ignore leap seconds when converting future EST/EDT/UTC-specified >moments into a timestamp. ENOCANDO, if we define a new API to deal with leap-seconds, it has to deal with leap-seconds correctly. -- 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
Re: [LEAPSECS] Lets get REAL about time.
Keith Winstein wrote: > Hmm, in practice I think the plan to simply fail with an error is > going to be a non-starter. Plenty of applications need to record dates > more than six months in the future; e.g. in a calendar program, the > user will want to schedule a meeting for August 1, 2012, from 9 a.m. > EDT to 10 a.m. EDT. The program will want to do all the normal things > -- calculate the duration of the meeting, how far in the future it is > (so it can put it in sorted order along with the other events of that > day), etc. In a subscription service, we might want to say that the > user's subscription lasts until January 22, 2013 at 12:21 p.m. (one > year hence) and give them a countdown (264 days remaining) as that > timestamp approaches. This is exactly why "REAL" time is simply wrong for most "civil" applications. That is also one of the reasons why I have rejected the idea of switching the time_t scale on my personal non-POSIX UNIX systems to a TAI-style one. What people like PHK fail to grasp is that a whole ton of applications absolutely DO NOT CARE how many Cs-133 transitions happen to occur in a given *civil* time interval, all they care about is a bijective mapping between their timestamps and *official civil time*. The SI second is the root of the problem. It should NOT be used outside of highly specialized scientific/technical context, i.e., it should NOT be used in civil contexts. In a civil application a 1 s timestamp increment is NOT an SI second, it represents the position of the hands of the official clock on the government building advancing by a certain angle, regardless of how many times a Cs-133 atom happens to flip while the hands of the official clock advance by an angle meaning 1 s. Each (micro-)nation should indicate its official time with an analog clock (i.e., one with rotating hands, not digital) on the wall of a government building specifically to drive the point home that notations like 23:59:60 are not acceptable. This non-scalar notation is the real fundamental problem with UTC in my eyes, *not* the length of advance notice for leap seconds (6 months is *far* more than should be necessary IMO), and that is why UTC should not be used directly by "normal" application. UTC should be rubberized in the way of UTC-SLS or Google's leap smear before being presented to "normal" applications and non-real-time operating systems such as 4.3BSD-Quasijarus. Back to the calendar and subscription applications, there is absolutely no reason why they can't store their timestamps with 1 s or finer precision indefinitely far in the future *and* have these timestamps be absolutely correct when that future moment arrives. BUT, these timestamps need to be reckoned on a NON-REAL time scale, i.e., they should not pretend to have any relation to time-as-in-physics and should merely represents particular points in the course of "analog" civil time, i.e., particular angular positions of the rotating hands of the official clock on the wall of a government building. An indication that Mary Q. Public's subscription expires at 2022-07-25T19:41:42 UT1 is perfectly precise and unambiguous regardless of how many leap seconds occur between now and then. The current non-POSIX UNIX definition of time_t (which is identical to the POSIX definition with the exception of making absolutely no reference to "UTC") which measures the angular position of the hands of a civil analog clock with no reference to physical time is perfect for most "normal" civil applications. Forcing such systems to maintain TAI-style time in the kernel and converting to civil time in the userland via leap second tables (which is what PHK's REAL time proposal does in essense) is nothing but an unnecessary burden. Why burden a system with leap second tables if it doesn't need them? If a system needs interval (as opposed to civil or time-of-day) timekeeping only in a very very crude sense, as most "normal" systems do, it is much simpler to make the system _explicitly not care_ about "atomic" time and maintain its notion of time solely as a representation of the civil clock-hands angle, which is also usable as a crude measure of interval time. A typical example of what I mean by a system needing interval time only in a very very crude sense: consider a secondary DNS server periodically contacting the primary master to see if its zones need an update (that's a typical use of interval timekeeping on the kind of computer systems I run). This refresh interval is specified in the DNS SOA record in units called "seconds", without further qualification. On the one hand, this ought to mean interval time rather than time-of-day: there doesn't seem to be any sensible reason why the interval between DNS zone refreshes should depend on Earth's rotation. Hence the natural interpretation of RFC 1035 would be to take the times in the SOA record as being in SI seconds. But the OS on which my DNS servers run has no knowledge of SI seconds,
Re: [LEAPSECS] Lets get REAL about time.
On Sat, Jan 21, 2012 at 7:09 PM, Poul-Henning Kamp wrote: > In message > > , Keith Winstein writes: > >>You are saying that if the time given is more than six months in the >>future, realtime_tm() will simply return an error and will not be able >>to produce a human-readable timestamp (whether in UTC, EST, EDT, CET, >>BST, etc.). > > Correct, if we don't have the knowledge to do it, we fail the conversion. >>Isn't this a problem? > > If it is, it's a not problem with the API, but with the way > leap-seconds are defined. Hmm, in practice I think the plan to simply fail with an error is going to be a non-starter. Plenty of applications need to record dates more than six months in the future; e.g. in a calendar program, the user will want to schedule a meeting for August 1, 2012, from 9 a.m. EDT to 10 a.m. EDT. The program will want to do all the normal things -- calculate the duration of the meeting, how far in the future it is (so it can put it in sorted order along with the other events of that day), etc. In a subscription service, we might want to say that the user's subscription lasts until January 22, 2013 at 12:21 p.m. (one year hence) and give them a countdown (264 days remaining) as that timestamp approaches. Perhaps you envision a whole other, separate API for representing and validating EDT (and other civil time, and UTC) timestamps and doing approximate arithmetic on them until the happy moment when they can finally be successfully converted into a realtime_t, but if so this introduces considerable extra complexity and will need to be specified. People are going to want to evaluate the whole package of what they're getting into before they sign on to this thing. The notion that "the API" can do nothing more than report an error message is not quite right. There are some alternatives: 1) Ignore leap seconds when converting future EST/EDT/UTC-specified moments into a timestamp. ==> This is the current POSIX status quo, and it works pretty well for the vast majority of applications. 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. ==> This is the current status quo using the "right" timezone files. 3) Correctly account for past leap seconds, and bomb out with an error when converting future EST/EDT/UTC-specified moments. ==> This is your proposal. 4) In addition to the "double *error" returned by tai_time(), also report an error estimate from the conversion routines realtime_tm() and tm_realtime(), reflecting the uncertainty from the fact that future leap seconds may not be known far enough in advance. The conversion to and from UTC is uncertain, but not totally unknowable. Calendar applications might be perfectly happy with a +/- 10 second error on a timestamp years in the future. 5) Instead of a quantitative estimate from #4, you could simply return a boolean reflecting whether the conversion is exact or might be some seconds off because of as-yet-unannounced leap seconds. That is, instead of "bomb out and return an error" for future timestamps, the API can "do the best conversion possible and return a warning if necessary." === On balance, I think #5 may be the best compromise between usability and correctness. And it is much more likely to be accepted than an API that rigidly bombs out for timestamps in the future, just because the conversion may be off by 1 second. Most applications do not need this level of accuracy for future timestamps but still want a conversion. -Keith ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , Bob Paddock writes: >I take issues with hardware requiring those kind of resources to keep >track of time. >There are more Embedded Systems today running at well under 100 MHz (or 10 >MHz), >and 128 Floating Point on them just isn't going to happen. Neither is, in my experience, any kind of timekeeping :-) One if the obvious ways to provide a "limited" functionality in my proposed API, is to allow any floating point type, with corresponding loss of resolution. This is an aspect I particularly like, with FP we won't loose range, only resolution. But shelve this issue for now, I want to start with an API which Does The Right Thing, and then move on from there, to see if this is feasible. >"TAI64, covering a few hundred billion years with 1-second precision; >(2) TAI64NA, covering the same period with 1-attosecond precision" See previous discussion about multi-radix formats. -- 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
Re: [LEAPSECS] Lets get REAL about time.
On Fri, Jan 20, 2012 at 6:29 AM, Poul-Henning Kamp wrote: > Modern CPUs clock around 4GHz, multiplying by 1000 for resulution we > find that we need 42 bits after the binary point. >IEEE binary128 floatingpoint I take issues with hardware requiring those kind of resources to keep track of time. There are more Embedded Systems today running at well under 100 MHz (or 10 MHz), and 128 Floating Point on them just isn't going to happen. These systems do need to keep accurate time just as the bigger systems do. > 77 bits is pretty far from 64 bits, and already today, 42 years > from our epoch, 64bit resolution have 4% error on nanoseconds, > that's not workable. Don't know that it helps your goal, there is already LibTAI http://cr.yp.to/libtai.html : "TAI64, covering a few hundred billion years with 1-second precision; (2) TAI64NA, covering the same period with 1-attosecond precision" -- http://blog.softwaresafety.net/ http://www.designer-iii.com/ http://www.wearablesmartsensors.com/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Poul-Henning Kamp said:
>>> #define timespecsub(vvp, uvp) \
>>> do {\
>>> (vvp)->tv_sec -= (uvp)->tv_sec; \
>>> (vvp)->tv_nsec -= (uvp)->tv_nsec; \
>>> if ((vvp)->tv_nsec < 0) { \
>>> (vvp)->tv_sec--;\
>>> (vvp)->tv_nsec += 10; \
>>> } \
>>> } while (0)
>>>
>>> Lovely, isn't it ?
>> Unlovely, but not the ugliest, especially considering that there may
>> not have been a better way at the time.
>> The 'do { ... } while (0)' kludge is at least as ugly as its contents[...]
> The do {...} while(0) is the least ugly way to make function-like CPP
> macros safe for below average programmers IMO.
For below-average programmers to write, perhaps. The obvious way for a
competent programmer to write this without that horrible hack is:
#define timespecsub(vvp, uvp)\
((vvp)->tv_sec -= (uvp)->tv_sec, \
(vvp)->tv_nsec -= (uvp)->tv_nsec, \
((vvp)->tv_nsec < 0)\
? ((vvp)->tv_sec--, (vvp)->tv_nsec += 10) \
: (void) 0)
This has the advantage of being usable wherever a function can appear.
Of course, since it evaluates its arguments multiple times, the usual
convention is to put the name in uppercase.
But with a modern compiler I'd just write it as a function (possibly an
inline one) and let the compiler worry about efficiency.
--
Clive D.W. Feather | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 23:27, Poul-Henning Kamp remarked: This is not a current standard C interface, this is *new* C interface that does it right. Ooops, sorry! I overlooked that. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012 Jan 21, at 14:34, Zefram wrote: > This is a reason for having a distinct representation of UTC timestamps. > You can have a future UTC time, and convert it between UTC and (say) > London time, without being able to represent it as a realtime_t. I guess > you need a conversion interface that accepts *two* tz parameters (source > and destination). Someone should correct me if I'm wrong, but it is my impression that the TC TIMEZONE folks (who are largely a continuation of the folks who fixed up the iCalendar standard for its new family of RFCs) are dealing with exactly this sort of thing. Note that the problem of assigning a timestamp to a future event is problematic simply because of bureaucrats changing the rules for timezone events, and in that sense the TAI value for a future event expressed in local time may not be predictable less than a week in the future, at least based on the experience of the folks who maintain the tz database. -- 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] Lets get REAL about time.
In message , "Josep h S. Myers" writes: >On Sat, 21 Jan 2012, Poul-Henning Kamp wrote: >For compatibility with existing binaries [...] Lets leave that for later. Right now I want us to come up with a API design which handles time correctly. Once we have that in place, we can look at what it takes to get it pushed into the real world. So forget time_t and all that stuff for now, and lets make sure realtime_t and its standard API does the right thing. PS: And no: you don't need the kernel to offer the compat API's, you can do that in your shared libc. -- 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
Re: [LEAPSECS] Lets get REAL about time.
On Sat, 21 Jan 2012, Poul-Henning Kamp wrote: > >My question, though: if the offset is in TAI, and you have to > >support "UTC", how do you get your leap second tables to do the > >conversion? > > The reason for TAI is that way the kernel will not need the leapseconds > only userland will. The kernel will presumably have new system call interfaces using the new type. For compatibility with existing binaries it will also need all the existing interfaces using the existing types with the same semantics as at present (for example, POSIX time_t as an arithmetic encoding of UTC broken-down times that is ambiguous around leap seconds) - and so will need a way to convert between the two. Similarly, new filesystems may have an on-disk format using the new type for timestamps - so requiring a conversion to time_t when old stat() interfaces are called - but for old filesystems it will remain necessary to interpret on-disk timestamps in the same way they always were interpreted as time_t, meaning conversion code when a new interface is used with an old fileystem. For all these conversions, a leapsecond table in the kernel (presumably provided by userspace to the kernel during the boot process, and updated as needed after boot, rather than compiled in). If an interface like the proposed one had been used from the start then you could avoid kernel leapsecond tables - but in the real world of existing binaries, interfaces and on-disk formats with existing defined semantics, the kernel support is needed for backwards compatibility. -- Joseph S. Myers j...@polyomino.org.uk ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , Keith Winstein writes: >On Sat, Jan 21, 2012 at 7:44 AM, Poul-Henning Kamp wrote: > >> libc will need an updated table of leap-seconds to give you UTC, >> and if you hand it a timestamp that is more than some set delta-T >> from the last entry in the leapsecond table, it will return E2BIG >> rather than give you a potentially wrong timestamp. > >My concern is with this part of the proposal. > >You are saying that if the time given is more than six months in the >future, realtime_tm() will simply return an error and will not be able >to produce a human-readable timestamp (whether in UTC, EST, EDT, CET, >BST, etc.). Correct, if we don't have the knowledge to do it, we fail the conversion. 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. Bulletin C 42 came july 8th 2011 and says "until futher notice" Bulletin C 43 came january 5th 2012 and says "until futher notice" It seems to be like "6 months less one week" notice. Since leapseconds can happen in any month, I guess that gives us a validity window to 7 months, less 8 days from the the last recorded bulletin-C. That again, tells us how fast we have to distribute leap-second lists: we have less than three weeks, from we receive Daniel Gambis email. >Isn't this a problem? If it is, it's a not problem with the API, but with the way leap-seconds are defined. -- 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
Re: [LEAPSECS] Lets get REAL about time.
In message <20120121215737.ga17...@lake.fysh.org>, Zefram writes: >Poul-Henning Kamp wrote: >struct timeval and struct timespec have an obvious benefit: durations that >are short decimal fractions of the second can be represented exactly. The reason for timeval using microseconds has nothing to do with any kind of high-level thought about APIs etc. It was quick hack that took a copy of the 1MHz counter on the platform where the timeval was first introduced in a piece of phd-ware. I'll leave as an exercise to the archaeologically minded readers to to deduce which phd-ware, platform and guilty party. I think we have established that binary128 can also do that for all relevant definitions of "exactly", and not only that, it can be done in the purest terms imaginable in the source code: t1 = t0 + 1e-3; // same place, one millisecond later... >You want a fixed-point format. [...] No I don't because there are no standardized fixedpoint formats wider than 64 bit in existence. What's worse: There are no fixed-point-with-fraction formats available at all, so the conversion problems you worry about, would get much worse, as the above statement becomes totaly unreadable in the source code: t1 = t0 + 18446744073709552ULL; // 1 msec later The aim here is to make it possible to get a correct answer to the question "What time is it" and to make it as hard as possible for clueless programmers to get timekeeping wrong. >I think this API should be specified so that realtime_t can be an >arithmetic type where the compiler supports it, and can be a struct (of >two 64-bit ints) where necessary. Then we might as well have two different and incompatible APIs, and we all knows what kind of stuff that leads to: https://www.varnish-cache.org/docs/2.1/phk/autocrap.html No, I want _one_ API, and I want it to be done right so we don't have to mess with it again in my lifetime. >>If the error parameter is NULL, and the one sigma error estimate >>is larger than 0.1 second, the call returns a negative number and >>sets errno to EACCESS. > >I'm uncomfortable about the arbitrary number. I think this semantic >would be better as a separate function where one passes in a maximum >acceptable error. No, I want to have a well defined, bound of tolerance to make it easy to do the right thing. We can argue if the correct tolerance is 0.1 or 1.0 second, but it isn't larger. >>This call returns a monotonically increasing estimate of elapsed >>time in SI seconds, since the program started. > >Elapsed in which reference frame? In what ever reference frame the program is executed, for what ever we mean by "executed". The level of trouble you get into in relativistic situations will require not a realtime_t but a realspace_t type, and I'm not going to even attempt to define an API for that. I do appreciate the fine points you are trying to drag out here, but I think we are waay into discussing deck-chair arrangement here, and I'd really prefer to focus on the iceberg. >>The timestamp is outside the valid range of translation tables >>available to the program (errno = E2BIG) > >Should be EDOM, for domain error. Works for me. >So be aware that the `timezone' mechanism will have to be a bit more >sophisticated than the current Olson system. That is outside the scope of this API: What other "tz" values are supported than "UTC" (and possibly "TAI") is an implmentation issue. -- 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
Re: [LEAPSECS] Lets get REAL about time.
In message <4f1b223c.30...@yahoo.com>, Michael Deckers writes: > > On 2012-01-21 18:58, Poul-Henning Kamp asked: > >> Why on earth would you even want to specify a difftime ? > > Because it is required by standard C? This is not a current standard C interface, this is *new* C interface that does it right. -- 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
Re: [LEAPSECS] Lets get REAL about time.
Keith Winstein wrote: > I'm guessing many programs would fail, because >they often try to localtime() a time_t that is months in the future. This is a reason for having a distinct representation of UTC timestamps. You can have a future UTC time, and convert it between UTC and (say) London time, without being able to represent it as a realtime_t. I guess you need a conversion interface that accepts *two* tz parameters (source and destination). -zefram ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Sat, Jan 21, 2012 at 7:44 AM, Poul-Henning Kamp wrote: > libc will need an updated table of leap-seconds to give you UTC, > and if you hand it a timestamp that is more than some set delta-T > from the last entry in the leapsecond table, it will return E2BIG > rather than give you a potentially wrong timestamp. My concern is with this part of the proposal. You are saying that if the time given is more than six months in the future, realtime_tm() will simply return an error and will not be able to produce a human-readable timestamp (whether in UTC, EST, EDT, CET, BST, etc.). Isn't this a problem? Plenty of applications try to display dates and times (both in the local time zone and in UTC) that are more than six months in the future. E.g. calendar programs, the at tool, astronomy programs, billing software, accounting software, Web browsers (e.g. showing cookie expirations in human-readable form). Not all of these programs _display_ future timestamps to a resolution of 1 second (or 2^-112 second in your case), but many of them will want to do the conversion and then truncate the display precision. That conversion becomes impossible here. Imagine if we implemented localtime(), gmtime() and ctime() functions on top of this API -- I'm guessing many programs would fail, because they often try to localtime() a time_t that is months in the future. How would you handle this? -Keith ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Poul-Henning Kamp wrote: >How anybody could get the demented idea that a mixed-radix format >for time representaiton could be a smart move is totally beyond me. struct timeval and struct timespec have an obvious benefit: durations that are short decimal fractions of the second can be represented exactly. I think this should not be lightly dismissed. Mixed radix is silly, sure, but to have the quantum be a decimal, rather than binary, power of the second is useful. It gets along well with the ways we represent times and durations for human use, which are all decimal. If you use binary fractions then you'll have to convert between decimal and binary fractions a lot, and you'll run into rounding issues. In that case you should probably work out some conversion rules that round-trip values correctly to some appropriate precision. When representing time in a single binary quantity, you could avoid the conversion pain by counting attoseconds rather than fractional seconds. This has the inconvenience that pulling out the seconds part requires performing a division, rather than just ignoring some of the bits. But you're not encouraging that sort of operation anyway. I'm personally ambivalent about this. I appreciate the purity of using binary fractions of the second, but the conversions are so prevalent that an exact representation for decimal fractions (down to attoseconds) looks like a worthwhile tradeoff. There's an interesting precedent: the conventional 32.184 s difference between TT(TAI) and TAI appears to have been chosen not merely as a terminating-decimal number of seconds, but as a terminating-decimal number of *days* (0.0003725 days). In general a terminating-decimal number of seconds doesn't have this property, and it's a useful property since TT is frequently described in MJD terms. >How many bits of resolution do we need ? I agree with you that a 128-bit type is appropriate. I came to the same conclusion myself some time ago, for the same reasons. I had a vague intention to work up a full API as you have done, but for many years now my libraries have been mostly for Perl rather than for C. >We could invent a new data type, "int80_t" or something, but that >would be a lot of work, so let us just bite the bullet and use one >we already have: IEEE binary128 floatingpoint, also known as >quardruple-precision floating point. On this I firmly disagree. Floating point brings in a huge swath of complicated behaviour that you don't want. The changes of quantum that occur at exponent boundaries will hurt, especially since you'll be quite often subtracting two timestamps that are close together. Then there's the bizarre behaviour of zeroes, and the exotic infinities and NaNs. You don't want any of that for this purpose. You want a fixed-point format. Either 64.64 with the second as unit, or 128.0 with the attosecond as unit. True, C doesn't commonly offer an arithmetic type with this sort of behaviour. (And, of course, it doesn't offer native non-integer fixed-point support at all.) But that's a temporary problem. 64-bit ints became commonly available before the standard changed to mandate them, and 128-bit ints will inevitably go the same way. You'll kick yourself later if you permanently compromised on the semantics to get some implementation convenience for the first five years. I think this API should be specified so that realtime_t can be an arithmetic type where the compiler supports it, and can be a struct (of two 64-bit ints) where necessary. In fact, you're pretty much forced to do this anyway: IEEE quad-precision floats are not all that widely available. This does mean that the API user can't rely on being able to perform native C arithmetic on realtime_t values, and you'll need a bunch of macros to portably express the operations. But in a decade realtime_t will be an arithmetic type on everything in significant use, and programmers will be able to use the native arithmetic operations with only a small loss of backcompat. The switch from structs to native types can even be managed to preserve binary compatibility, provided struct-based implementations think ahead. >Our new timecale should run on the TAI timescale which does not >have leap-seconds or any other artifacts, Careful here. TAI can be projected back, by retrospective application of the definiton of the atomic second, to mid-1955. But prior to that there wasn't continuous (or pretty soon any) operation of atomic clocks, and hence there is no TAI. I believe you're intending that your time API be good for use on much older dates. If you want to be able to process dates prior to 1955, your time scale cannot be unadulterated TAI. There is, of course, a time scale that ticks pure SI seconds prior to 1955: TT. You could define that your timestamps notionally track TT, and then you can perfectly well have a Carboniferous-era timestamp. If you do notionally track TT, there remains a problem with contemporary
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 18:58, Poul-Henning Kamp asked: Why on earth would you even want to specify a difftime ? Because it is required by standard C? If you do not want to conform to standard C then you are designing new language and can of course do anything you like. But getting it into Standard C will be hard -- it has been tried on several occasions without success. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message <4f1b06d9.7060...@yahoo.com>, Michael Deckers writes: > Example questions: does difftime() set the inexact flag? Why on earth would you even want to specify a difftime ? People have two FP's then can subtract them, case closed. difftime() is only necessary when you have bogo-types like timeval, and avoiding such messes is exactly why I want the FP in the first place. -- 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
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 15:54, Poul-Henning Kamp wrote: timeval contains bogus combinations of tv_sec and tv_usec and a lot of code does not even notice... Yes, in contrast to IEEE binary floating point values where each and every bit pattern belongs to one of the classes FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, or FP_ZERO. I already specified that you get EINVAL if it is not a valid floating point number. I may have to be more specific than "valid" but I really don't see this a problem, considering how trivial and fast this is to check, compared to the math needed to get to, for instance UTC. Yes, a specification had to clarify what the term "valid floating point number" means. More to the point: IEEE arithmetic adheres to a well-defined (and sophisticated) computational model, and I believe users would expect that model to be followed if time_t was an IEEE float. Case in point: difftime() should react in the standard way on arguments that are signalling or quiet NaNs -- even if the programers don't care or don't know, their debuggers may rely on it. Of course, you are right that all this can be reasonably specified (with some effort). May be this is what BSD users REALly want to be in (or in ). You probably know best how to find out. > Moreover, IEEE floating point operations depend on certain > environmental settings (eg, rounding modes and enabled > traps) and it is not clear whether a system call must or > can use those of the caller in every circumstance. I'm not sure I can see how it can become relevant, given a good quality library implementation. Example questions: does difftime() set the inexact flag? does it use the rounding mode in force at the call? (People do interval arithmetic by executing their algorithm twice with different rounding modes.) Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , Rob Seaman writes: >Timestamps are preserved in various data structures for instance >as identifiers. Two such may need to be compared. If so, whoever uses it as an indentifier had better make sure he saves all 128 bits ? -- 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
Re: [LEAPSECS] Lets get REAL about time.
Poul-Henning Kamp wrote: > Rob Seaman writes: > >> 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. > > I don't know any valid usecase for testing timestamps for validity, > except for testing for programming errors. Timestamps are preserved in various data structures for instance as identifiers. Two such may need to be compared. If the full 128 bits are preserved these will serve as well as any other unencrypted hash, but until the layer above this is designed it isn't clear exactly how the base library will be used. Timestamps may also originate on different hosts, slaved to much less precisely than the Planck time, Bohr radius or "QED events" by NTP or what have you. Two such from two different hosts may need to be compared for proximity / equality. A library method(s) for doing so is desirable so that it isn't reinvented for each application with different epsilons, open/closed interval ambiguities, etc. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , Rob Seaman writes: >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. I don't know any valid usecase for testing timestamps for validity, except for testing for programming errors. -- 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
Re: [LEAPSECS] Lets get REAL about time.
Poul-Henning Kamp wrote: > Michael Deckers writes: > >> Comparing IEEE floating point values holds its surprises >> because values may be incomparable, > > In which case they are not valid timestamps, and you get > EINVAL if in a library or whatever you asked for in your > own code. Testing for equality of timestamps? For floating point this requires some sort of epsilon test. (Perhaps I missed this in the discussion.) Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message <4f1ade6d.8070...@yahoo.com>, Michael Deckers writes: > For one thing, IEEE float values contain infinities and > NaNs, and since the POSIX interfaces accept time_t values > as inputs, ths system code would have to deal with them. timeval contains bogus combinations of tv_sec and tv_usec and a lot of code does not even notice... I already specified that you get EINVAL if it is not a valid floating point number. I may have to be more specific than "valid" but I really don't see this a problem, considering how trivial and fast this is to check, compared to the math needed to get to, for instance UTC. > Moreover, IEEE floating point operations depend on certain > environmental settings (eg, rounding modes and enabled > traps) and it is not clear whether a system call must or > can use those of the caller in every circumstance. I'm not sure I can see how it can become relevant, given a good quality library implementation. > The timestamps of computer operating systems are often > used in a way where mainly the sequence of increasing > values is important, not so much their absolute value. That is why I added the "run_time()" version also. > Comparing IEEE floating point values holds its surprises > because values may be incomparable, In which case they are not valid timestamps, and you get EINVAL if in a library or whatever you asked for in your own code. -- 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
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 12:31, Poul-Henning Kamp wrote in reply to comments on his proposal for time_t as 128 bit binary float: First of all, I'm not particular wild about floating point numbers, but the fact of the matter is that: A: Time is measured in seconds, with a fractional part. B: We want a datatype which supports normal sums and differences. Both of which point to a floating point format, where operations will naturally do what people expect from them. And there is prior art: in the Apple Mac OSX operating system, the system call CFAbsoluteTimeGetCurrent() returns time as seconds since 2001-01-01 as a double value. When timestamps of computer operating systems are used to represent the physical time (of the call), a floating point representation is a good choice, so I do not want to argue against it. I just think that the additive structure of IEEE float values is much more involved than the additive structure of timespec and timeval. For one thing, IEEE float values contain infinities and NaNs, and since the POSIX interfaces accept time_t values as inputs, ths system code would have to deal with them. Moreover, IEEE floating point operations depend on certain environmental settings (eg, rounding modes and enabled traps) and it is not clear whether a system call must or can use those of the caller in every circumstance. A temporary switch in these settings may be needed. The timestamps of computer operating systems are often used in a way where mainly the sequence of increasing values is important, not so much their absolute value. Comparing IEEE floating point values holds its surprises because values may be incomparable, or can compare equal and still be distinct, and the conversion to and from a decimal notation of a binary floating point value is no easy matter if it is supposed to strictly preserve order. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message <7abcfe74-4bcc-40bf-8421-b0868a6c3...@noao.edu>, Rob Seaman writes: >Poul-Henning Kamp wrote: > >> First of all, I'm not particular wild about floating point numbers, > >Then others will feel the same way and will always immediately >cast the returned values into integers, either rounding to seconds, >scaling to milli- or microseconds, or splitting into two ints holding >the seconds and the fractional part. As they well should, and well should be able to. That's sort of the point really: Making sure programs do what programmers expect them to do, without having to write an entire book about how to find the time of day. Representing time as a real number that acts the way real numbers do, is the least confusing representation of time, as you yourself pointed about in re: MJD. >I'm not arguing against your position (perhaps for it), but the >API should be designed to gracefully handle awkward usage. In >particular, should truncating into 32-bit signed ints leave you in >a "reasonable" range of dates? 32 bits of int counted in seconds only holds 136 years of time, so you cannot ask that question without also asking "when" it should be "a reasonable range of dates". Having asked the question correctly, the answer is obvious: If the programmer think that is a safe restriction on his program. >> With binary128 we get 112 bits, which is enought to time individual >> QED events in the Carboniferous Era. > >This was the point about the Planck time. The universe is big and >time is long. No single API can address all use cases. Using binary128 gets pretty damn close: log10(2^112 / age of universe) = 16 log10(2^112 / 1000 years) = 23 (Technically speaking it should be 2^113, because we also have the sign). I'm pretty sure the major criticism will be that the range (and thus size) is far bigger than necessary. -- 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
Re: [LEAPSECS] Lets get REAL about time.
Poul-Henning Kamp wrote: > First of all, I'm not particular wild about floating point numbers, Then others will feel the same way and will always immediately cast the returned values into integers, either rounding to seconds, scaling to milli- or microseconds, or splitting into two ints holding the seconds and the fractional part. I'm not arguing against your position (perhaps for it), but the API should be designed to gracefully handle awkward usage. In particular, should truncating into 32-bit signed ints leave you in a "reasonable" range of dates? And if you are actually considering placing the epoch in the future, what are the implications for casting the values into unsigned ints? > With binary128 we get 112 bits, which is enought to time individual QED > events in the Carboniferous Era. This was the point about the Planck time. The universe is big and time is long. No single API can address all use cases. Choosing the applicable range and establishing edge case boundaries is an important part of the exercise. It will strengthen, not weaken, the design to describe its constraints accurately. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
In message , Mark Calabretta writes:
>> #define timespecsub(vvp, uvp) \
>> do {\
>> (vvp)->tv_sec -= (uvp)->tv_sec; \
>> (vvp)->tv_nsec -= (uvp)->tv_nsec; \
>> if ((vvp)->tv_nsec < 0) { \
>> (vvp)->tv_sec--;\
>> (vvp)->tv_nsec += 10; \
>> } \
>> } while (0)
>>
>>Lovely, isn't it ?
>
>Unlovely, but not the ugliest, especially considering that there may
>not have been a better way at the time.
That's simply not true, they could have chosen a binary fraction
rather than a decimal one.
>The 'do { ... } while (0)' kludge is at least as ugly as its contents[...]
The do {...} while(0) is the least ugly way to make function-like CPP
macros safe for below average programmers IMO.
>parallels in FPU microcode.
Average programmers don't get near the FPU microcode, they do have
to handle timevals on a regular basis.
>It's more natural to represent a physical quantity with a floating-
>point number. However, I would question the current availability of
>IEEE binary128 implementations. Are you assuming that the lead time
>for this proposal would overlap its wider adoption?
To put it bluntly: If people/OS's cannot get their shit together and
implement stuff like this, I don't care about them, because they will
be gone in less than five years anyway.
You can still use part of this API by defining an opaque type for
realtime_t, but you don't get the convenience of being able to
subtract them algebraicly, so there is a workaround until you get
your compiler people beaten up.
>... a local approximation of the TAI timescale ...
I assumed that people on this list knew if they were employed at BIPM
or not :-)
yes, just like the UTC is an estimate or approximation. I don't think
the document becomes significantly clearer by stuffing this into the
text, but an editorial footnote to keep BIPM happy is clearly in order.
>>A IEEE binary128 number containing time on the TAI timescale
>>counted in SI seconds since 2012-01-20 00:00:00 UTC.
>
>Is that your birthday by any chance?! I guess it's going to be
>a big one in 2026... I recently turned 20,000 myself.
In fact it is, but it was also the day I wrote the proposal, so
I have credible deniability :-)
>>]] int tai_time(realtime_t *timestamp, double *error);
>
>I suggest calling it something other than tai_time() as it will
>probably upset some people.
Suggestions ?
>However, the Caveats
>at http://www.ucolick.org/~sla/leapsecs/right+gps.html indicate the
>types of problems likely to surface in introducing the scheme,
The major caveat will be to get this API beaten into all relevant
operating systems in a timely fashion, everything else is just minor
matters of decisions to be made.
And yes, there will be transition effects and troubles, but I am not
going to attempt a new API if it doesn't solve the _all_ of the problems
with the current state of affairs.
>The rest of the API looks fine. I would also put in a request for a
>function that takes a realtime_t and returns the difference TAI-UTC,
>including the rubber-seconds era.
Ohh, absolutely, there needs to be a bunch of well thought out
convenience functions on top of this.
What I focused on here was solving the show-stopper problems:
1. Getting a sensible algebraic representation of time.
2. Getting the uncertainty of the estimate built in.
3. Get leapseconds moved to userland.
4. Getting an error rather than wrong time if leapsecond
information is not up to date.
--
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
Re: [LEAPSECS] Lets get REAL about time.
In message <83dfd8ce-fa06-49a7-b9a8-a562f1eb1...@bsdimp.com>, Warner Losh write s: >> 1) You'll get pushback against floating-point, especially quad >>FP. Benchmarks and data challenges are a good way to make the case. >>What is the cost to "get REAL" versus current libraries for different >>classes of systems and applications? > >And how do kernels convert from integer to float? If a kernel internally maintains time as 64.64 integer, turning this into a binary128 floating point value is a matter of stuffing the 64.64 into the mantissa field and normalizing the FP. 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. The major trouble right now, is that the time-types in POSIX sucks. If we want to improve it, we should make sure the improvement is an improvement. The choice of FP is to make time act like a sensible variable in programs, which would be a big improvement over timeval and similar crap: if (t1 - t0 > 0.25) do_that(); And FP is also indicated because binary128 is the only variable type currently in existence big enough to hold timestamps with sufficient resolution. >> 2) There is nothing magic about the 1000 year horizon. Certainly >> science cases extend very much further into the past and future. 1000 years was chosen as a bare minimum to estimate miniumum number of bits needed. With binary128 we get 112 bits, which is enought to time individual QED events in the Carboniferous Era. >> 3) How does this interoperate with Julian date, another >> floating-point format? Note that Modified Julian Date (MJD) was >> implemented precisely to avoid the extended precision needed to >> simultaneously support high precision and wide date ranges. There is no difference in the number of bits necessary, MJD is just a scale and an offset away from my realtime_t type. I think it is important that the unit of the representation is a second rather than a day, simply because most of the stuff computers do are in the second domain, not in the day domain. (See code example above) >My question, though: if the offset is in TAI, and you have to >support "UTC", how do you get your leap second tables to do the >conversion? The reason for TAI is that way the kernel will not need the leapseconds only userland will. libc will need an updated table of leap-seconds to give you UTC, and if you hand it a timestamp that is more than some set delta-T from the last entry in the leapsecond table, it will return E2BIG rather than give you a potentially wrong timestamp. NTP can transfer the leap-second table these days, and all sorts of software update mechanisms could as well. -- 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
Re: [LEAPSECS] Lets get REAL about time.
In message , Stephen Colebourne writes: >> >There is an IEEE spec for a large decimal number, which would be >> >preferable. Or a 96/128 bit integer. >> >> Only, it is not implemented anywhere, binary128 is. > >Fine, but I'm very unenthused about floating point numbers in general. >I'm not sure you've made your case for not using a 128 bit integer, >defined as (say) attoseconds. First of all, I'm not particular wild about floating point numbers, but the fact of the matter is that: A: Time is measured in seconds, with a fractional part. B: We want a datatype which supports normal sums and differences. Both of which point to a floating point format, where operations will naturally do what people expect from them. Representing time in a integer count of a decimal fraction of seconds is a really bad idea on a binary computer, that just leads to bugs. It also means that numeric contants for common time intervals like "1 second" become unweildy constants in the program. See timeval/timespec use for plenty of such messes. If you want a 128bit counter format, the units should be "1/2^N" for some suitable N, most likely 64. This would be workable, but still suffers from unweildy constants, in particular for time intervals less than a second. I've come to the conclusion that we have two choices: Either a totally opaque time-type, which can only be operated on with function calls that understand it, or we can lay it out in a floating point type that intuitively does what people expect with common algebraic operations. The latter is clearly preferable, if the objective is to reduce the number of mistakes programmers make. >Exactly why I was asking about the purpose of this API. I'm not seeing >it as a time API. My intention was that this would be API that interfaces programs to the operating systems (ie: kernels) timekeeping facility. >My concern with what you have proposed is >that the second part (the time-zone part) does imply a time API, but >without sufficient control. What controls are missing ? >The JSR-310 spec effectively only requires a clock source from the OS. And my API specifies the API to that clock source. >Currently, my view is that the low-level API that you are defining >should offer all three of the above, as they are the building blocks >for everything else. Exactly. >Finally, I do think that if its called TAI, then it should use the TAI >epoch. No, to aid finding programmer bugs, it should use an epoch that will generate large errors if^H^Hwhen programmers make mistakes. -- 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
Re: [LEAPSECS] Lets get REAL about time.
On 20 January 2012 16:31, Poul-Henning Kamp wrote: > >There is an IEEE spec for a large decimal number, which would be > >preferable. Or a 96/128 bit integer. > > Only, it is not implemented anywhere, binary128 is. Fine, but I'm very unenthused about floating point numbers in general. I'm not sure you've made your case for not using a 128 bit integer, defined as (say) attoseconds. > >When designing the Java API, I concluded that it was a user choice as > >to the time-scale they wanted. There are three choices: > > That is not "solving" the problem, that is "kicking the can down > the road" :-) > > But then again, Java is a different environment, and I think we > should look at Java as implmented on top of OS services, not > the other way around. Exactly why I was asking about the purpose of this API. I'm not seeing it as a time API, but as a clock API. A time API would have other constraints and functions. My concern with what you have proposed is that the second part (the time-zone part) does imply a time API, but without sufficient control. > >I don't believe its what users *want* (it forces every query of > >seconds to have to handle leapsecs, which is undesirable for API > >usability). > > Remember, this may not be the API the user sees, there would very > likely be an intermediate level of "convenience" functions. What > I am trying to describe is the _lowest level_ of timekeeping service > available, the one that can support "all of the above". I think that the proposal/spec needs to be very clear on its goals in the writeup. FWIW, the Java world already has its own copy of the time-zone data files, and the JSR-310 spec makes use of the leap secs data from those as well. But not that is direct use, not use of the OS copy. (And there is a vague plan to allow over-the-air updating of time-zone data, which would include leapsecs, but again, only to Java) The JSR-310 spec effectively only requires a clock source from the OS. The API allows the source to be TAI (secs, nano-of-sec), UTC (mjday, nano-of-day) or 86400 (something that provides 86400 secs per day in line with the standard civil time, which should ideally be smoothed in some way at leap second). Currently, my view is that the low-level API that you are defining should offer all three of the above, as they are the building blocks for everything else. An implementor would code one, and write conversions to the other two in likelihood, but it means that you are forcing less of existing implementations. ie. think of it as a possible transition approach. Finally, I do think that if its called TAI, then it should use the TAI epoch. BTW, the UTC before 1972 issue is a problem. FWIW, JSR-310 currently defines the TAI-UTC offset as always 10s before 1972, even though that is obviously not historically accurate. Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Jan 20, 2012, at 10:54 PM, Rob Seaman wrote: > Poul-Henning Kamp wrote: > >> To avoid thread-divergence, I have collected some responses here: > > Am happy to see such an effort and agree generally with previous comments, > expecially Mark's and Steve's. Will keep my editorial comments to a minimum > (here) to squelch divergence, but I will point out that this of course > doesn't address all civil timekeeping issues that have been discussed. > > Regarding editorial comments, would suggest these be excised from the > document but that points of software engineering be described in more detail > than usual; the stakeholders and potential readers won't all be programmers. > For instance, examples of bad current usage should explain why they are bad. I was thinking they should be split into an appendix... >> Also, I disagree with choosing an epoch in the past to reduce exponent >> changes: We should optimize to get maximum number of exponent changes >> initially, to make sure code handling that gets debugged. We should >> probably even put the epoch into the future, >> to also get handling of signs tested. Lets make it 2026-01-20 instead. > > An interesting strategy. Some comments: > > 1) You'll get pushback against floating-point, especially quad FP. > Benchmarks and data challenges are a good way to make the case. What is the > cost to "get REAL" versus current libraries for different classes of systems > and applications? And how do kernels convert from integer to float? > 2) There is nothing magic about the 1000 year horizon. Certainly science > cases extend very much further into the past and future. If you have a design goal of 1000 years, then that's forever in CS terms. It lets you show that the problem will be effectively solved with several bits to spare. Those several bits might be used to leverage longer time horizons. We have astronomical data from only the past 500 years to a high precision, and less precise back another 5000 years (is that right?) But since my son loves dinosuars, I know they were 200M years ago, and the age of the earth is like 5B years and the age of the universe is 20B years. That's about 1e18 seconds (if I did the math right) which is about 56 bits of SI seconds, which leaves 56 bits for the fraction (assuming it is float), which should be adequate for all users. Unless I'm doing something wrong with the math somewhere... > 3) How does this interoperate with Julian date, another floating-point > format? Note that Modified Julian Date (MJD) was implemented precisely to > avoid the extended precision needed to simultaneously support high precision > and wide date ranges. MJD/JD are just transforms... With 112 bits of precision, the reasons for MJD vs JD disappear. They were made for when you had far fewer bits of precision... My question, though: if the offset is in TAI, and you have to support "UTC", how do you get your leap second tables to do the conversion? And do you use UTC'72 projected back into the past from 1972? Or do you use the 10 rubber leap seconds to take us back to 1958? and prior to that what do you use? Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Poul-Henning Kamp wrote: > To avoid thread-divergence, I have collected some responses here: Am happy to see such an effort and agree generally with previous comments, expecially Mark's and Steve's. Will keep my editorial comments to a minimum (here) to squelch divergence, but I will point out that this of course doesn't address all civil timekeeping issues that have been discussed. Regarding editorial comments, would suggest these be excised from the document but that points of software engineering be described in more detail than usual; the stakeholders and potential readers won't all be programmers. For instance, examples of bad current usage should explain why they are bad. > Also, I disagree with choosing an epoch in the past to reduce exponent > changes: We should optimize to get maximum number of exponent changes > initially, to make sure code handling that gets debugged. We should probably > even put the epoch into the future, > to also get handling of signs tested. Lets make it 2026-01-20 instead. An interesting strategy. Some comments: 1) You'll get pushback against floating-point, especially quad FP. Benchmarks and data challenges are a good way to make the case. What is the cost to "get REAL" versus current libraries for different classes of systems and applications? 2) There is nothing magic about the 1000 year horizon. Certainly science cases extend very much further into the past and future. 3) How does this interoperate with Julian date, another floating-point format? Note that Modified Julian Date (MJD) was implemented precisely to avoid the extended precision needed to simultaneously support high precision and wide date ranges. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Fri 2012/01/20 11:29:18 -, "Poul-Henning Kamp" wrote
in a message to: Leap Second Discussion List
>I would like your comments on this API proposal, if we can agree
>that it workable, I am willing to push it, hard, in the UNIX world.
This ticks all the right boxes for me. Specific comments below.
> #define timespecsub(vvp, uvp) \
> do {\
> (vvp)->tv_sec -= (uvp)->tv_sec; \
> (vvp)->tv_nsec -= (uvp)->tv_nsec; \
> if ((vvp)->tv_nsec < 0) { \
> (vvp)->tv_sec--;\
> (vvp)->tv_nsec += 10; \
> } \
> } while (0)
>
>Lovely, isn't it ?
Unlovely, but not the ugliest, especially considering that there may
not have been a better way at the time. The 'do { ... } while (0)'
kludge is at least as ugly as its contents which I imagine would have
parallels in FPU microcode.
>We could invent a new data type, "int80_t" or something, but that
>would be a lot of work, so let us just bite the bullet and use one
>we already have: IEEE binary128 floatingpoint, also known as
>quardruple-precision floating point.
The conclusion that 64 bits is not enough but 128 bits will be is
easy to accept, and I agree with avoiding anything in between.
It's more natural to represent a physical quantity with a floating-
point number. However, I would question the current availability of
IEEE binary128 implementations. Are you assuming that the lead time
for this proposal would overlap its wider adoption?
en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Implementations
>Next comes the question what we do about leap-seconds, and there
>is only one answer that works in practice: We make them a
>representation issue.
Great!
>Our new timecale should run on the TAI timescale which does not
>have leap-seconds or any other artifacts, and library functions can
>convert that to UTC time, civil time etc, using a leap-second table
>which can be updated as and when leap-seconds gets announced.
... a local approximation of the TAI timescale ...
>Here is my proposed api:
>
>]] typedef $compiler_magic realtime_t;
>
>A IEEE binary128 number containing time on the TAI timescale
>counted in SI seconds since 2012-01-20 00:00:00 UTC. The exact
>epoch is not imporant, but it is a good idea to make it different
>from all other currently used epochs, to make programmer mistakes
>clearly visible.
Is that your birthday by any chance?! I guess it's going to be
a big one in 2026... I recently turned 20,000 myself.
>]] int tai_time(realtime_t *timestamp, double *error);
I suggest calling it something other than tai_time() as it will
probably upset some people.
>]] double tm_frac;/* fractional second [0...1[ */
>
>We treat UTC as another case of the larger class of civil timezones.
This now starts to overlap with Steve's TZ proposal which, in some
sense, this proposal would serve to legitimize. However, the Caveats
at http://www.ucolick.org/~sla/leapsecs/right+gps.html indicate the
types of problems likely to surface in introducing the scheme,
particularly those associated with heterogeneous computing
environments - i.e. where you have a mix of machines on a network
sharing files, etc., some running time_t and some running realtime_t.
I think that aspect needs to be thought out.
The rest of the API looks fine. I would also put in a request for a
function that takes a realtime_t and returns the difference TAI-UTC,
including the rubber-seconds era.
Regards, Mark
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On Jan 20, 2012, at 9:29 AM, mike cook wrote: >> Modern CPUs clock around 4GHz, multiplying by 1000 for resulution we >> find that we need 42 bits after the binary point. > > Solaris already has 64 bit quantities for time operations. From their doc: > > "time_t, and its derivative types struct timeval and timespec_t now contain > 64-bit quantities" > > Aren't you reinventing the wheel? Its open source, so just borrow it. typedef int64_t time_t; That's 64-bits for the seconds portion of things. There's not a similar partial seconds. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
To avoid thread-divergence, I have collected some responses here: Zefram writes: > I think he was suggesting that you use the 1958-01-01 epoch that NASA (and > I, in my desktop clock program) already use. I disagree, as a matter of software quality assurance, it is important to choose an epoch *nobody* else uses, so that conversions are forced to be explicit, rather than assumed automatic. Also, I disagree with choosing an epoch in the past to reduce exponent changes: We should optimize to get maximum number of exponent changes initially, to make sure code handling that gets debugged. We should probably even put the epoch into the future, to also get handling of signs tested. Lets make it 2026-01-20 instead. Steve Allen writes: >Nothing can tick TAI seconds, for TAI is not known until next month, >so at the nanosecond level that assumption must be false. A lot of things can tick TAI seconds at he level of precision required for most applications, and since the uncertainty is explicitly reported in my API, any remaining applications will have the data needed to cope or crash. >>[deriving TAI from UTC etc] >Indications have been that BIPM will disagree violently with that >statement. Only if you forget to specify the uncertainty. If you remember to specify the uncertainty, they're usually quite pleased. Michael Deckers writes: > To set the scale, the finest resolution possible with > the time of day register in IBM zArchitecture machines > is 2^-52 =B5s =3D~ 0.2 zs, which is 3 orders of magnitude > below your proposal. 112 bits still leave us good room. -- 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
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-20 15:46, Gerard Ashton wrote: For the smallest time resolution required, we might suppose that at some point in the future there might be a need to account for transmission delay from one part of a computer to another. The smallest location that I can imagine being of interest even in a future computer is the diameter of a hydrogen atom, about 0.1 nm. The time for light to travel this distance is about 3 as, or about 2^-58 s. Just a correction on your arithmetic: light travels at 0.3 m in 1 ns, so it takes only about 0.3 as for the distance of 0.1 nm, not 3 as. To set the scale, the finest resolution possible with the time of day register in IBM zArchitecture machines is 2^-52 µs =~ 0.2 zs, which is 3 orders of magnitude below your proposal. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
A more accurate statement is that a real time event can be labeled with measured time, M, by local device that keeps the TAI(h) time scale, and the TAI(h) time scale can be steered to UTC(k), GPS, or another broadcast time scale. The letter "k" designates a recognized time laboratory while "h" represents some hacker of unknown competence. Subsequently, when the IERS publishes the appropriate bulletin, a refined measured time, M', can be derived which removes the error in UTC(k), GPS, etc., but not the error in steering to that standard, nor any other measurement errors made by the local device. Gerard Ashton On 1/20/2012 2:18 PM, Michael Sokolov wrote: Steve Allen wrote: TAI can be derived from UTC, GPS and other broadcast timescales, so availability is fine. Indications have been that BIPM will disagree violently with that statement. And what's wrong with simply ignoring them after telling them to STFU? MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 1/20/2012 2:23 PM, Rob Seaman wrote, in part: There is plenty of prior art to consult here on both the CS side (early Crays already minimized cable runs to mitigate light speed constraints, it is commonplace today) and on the physics side (e.g., Planck units*). Workflow logistics and systems engineering are still needed to figure out the appropriate trade-offs for whatever purpose. There is unlikely to be one timekeeping methodology appropriate for all purposes, for instance this amazing video: http://web.mit.edu/newsoffice/2011/trillion-fps-camera-1213.html Rob -- * The Planck length is 25 orders of magnitude smaller than twice the Bohr radius (i.e., the diameter of a hydrogen atom). The Planck time is 5.391 x 10^-44 s, FWIW. The time scale which a computer must keep track of while operating is different than the time scale which must be considered while designing the computer. The former is more likely to be time-of-day or time-since-an-epoch while the latter is more likely to be duration. I have been involved in the design of computers with a 500 ps clock period but design calculations were carried out with a resolution of about 1 ps. A gross example of being aware of the location of various parts of a computer system would be an auction web site where bids are considered received when they arrive at any of the web site's servers. One solution would be to time-stamp the bids at the first server they arrive at; an alternate approach would be to subtract the transmission delay from the first-received server to the server that decides who won. It's difficult to predict what applications might require awareness of much shorter transmission delays. Gerard Ashton ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
