Robert E. Brown is not on the time zone mailing list; be sure to include Robert in any replies. --ado -----Original Message----- From: Robert E. Brown [SMTP:brownb@jany.gs.com] Sent: Thursday, August 26, 1999 1:24 PM To: tz@elsie.nci.nih.gov Subject: timezone improvements I work for a company that requires some capabilities beyond the standard time zone library. Here's the sort of thing we're interested in: Ability to efficiently do time calculations in several time zones at the same time in separate threads. Time zone functions might take a zone as argument instead of the current method of setting the TZ environment variable and calling tzset to change zones, which involves file I/O. Is there any prior art along these lines? I do see the routines whose names end with "_r". They seem to fix one glitch, but do not completely solve the problem. How can I get the capabilities I want integrated with the standard time zone library? By making it a part of the standard library, the chance increases that the code will be used, maintained, and completely debugged. We are willing to pay for the capabilities we want. Would Cygnus be a good source for this work? Do you have any other suggestions? Thanks very much. bob
"Olson, Arthur David (NCI)" quoted:
-----Original Message----- From: Robert E. Brown [SMTP:brownb@jany.gs.com] Sent: Thursday, August 26, 1999 1:24 PM To: tz@elsie.nci.nih.gov Subject: timezone improvements
I work for a company that requires some capabilities beyond the standard time zone library. Here's the sort of thing we're interested in:
Ability to efficiently do time calculations in several time zones at the same time in separate threads. Time zone functions might take a zone as argument instead of the current method of setting the TZ environment variable and calling tzset to change zones, which involves file I/O.
Is there any prior art along these lines? I do see the routines whose names end with "_r". They seem to fix one glitch, but do not completely solve the problem.
In order to completely solve this problem (and a few others), I have taken the time to write up a proposal for a modernized date/time interface for the C language: http://www.cl.cam.ac.uk/~mgk25/c-time/ I hope you will find this proposal a useful reference, and I also would expect that it suits your needs nicely. If not, please explain why! There exist no implementation at this point yet. I would be delighted if you would pay someone to implement it (or part of it). My hope is that the ISO C committee will look at this issue one day, but the proposal came too late to still go into ISO C 9X. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Date: Fri, 27 Aug 1999 01:23:06 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> I have taken the time to write up a proposal for a modernized date/time interface for the C language: http://www.cl.cam.ac.uk/~mgk25/c-time/ This message prompted me to install minor tweaks to my alternative proposal, inspired by yours but (I hope) simplified, which can be found at: http://www.twinsun.com/tz/timeapi.html David Tribble has an alternative proposal (dated 1998-07-14) at: http://www.flash.net/~dtribble/text/c0xtime.htm which I haven't managed to digest yet.
Paul Eggert writes:
I don't understand what problems you're trying to solve here. Time libraries should be designed to support the features that real programs need. For example: * Benchmarking tools need to measure differences in real time. Consider the gettimeofday() function. * Networking tools need to schedule events at moments in real time: e.g., send this packet 0.2 seconds after that one. Consider the select() and poll() functions. * Clock programs need to know the current time in the local time zone. Consider the time() and localtime() functions. * Mail readers, given a list of civil times from various time zones, need to sort the times into numerical order. Consider the mktime() function. * Calendar programs need to know tomorrow's date, the number of days until next month, etc. Evidently there are four basic objects here: * Calendar dates: year-month-day. * Civil times: year-month-day, hour-minute-second, zone. * Date intervals, expressed as a number of days. * Time intervals, expressed as a number of seconds. Arithmetic on intervals is trivial. To support arithmetic on calendar dates and civil times we can set epochs and provide a few fundamental conversions: * Convert seconds-since-epoch to a civil time in the local time zone. * Convert any civil time to seconds-since-epoch. * Convert days-since-epoch to a calendar date. * Convert a calendar date to days-since-epoch. If the system keeps track of the current time as seconds-since-epoch then we can convert it to civil time in the local time zone. ---Dan
I hope this is within the scope of this mailing list, if not please let me know where is a good place to discuss this. "D. J. Bernstein" wrote:
Paul Eggert writes:
I don't understand what problems you're trying to solve here.
Time libraries should be designed to support the features that real programs need. For example:
Your examples where perfectly good, but you left out some of the real fun calendar calculations. * scheduling programs that deal with humans need to be able to specify and calculate various relative moments in time. Examples include: the beginning next week, start of next month, two days before the beginning of the last month of the year, the last Thursday in November, exactly 60 days from now, exactly two months before now, the first day of this year, the beginning of the third month of this year etc.
Evidently there are four basic objects here:
* Calendar dates: year-month-day. * Civil times: year-month-day, hour-minute-second, zone. * Date intervals, expressed as a number of days. * Time intervals, expressed as a number of seconds.
But also there are sometimes needs for: * Time intervals, expressed as combinations of unspecified years, months, days, weeks, hours etc. Plus those folks who happen to calculate better than seconds need. * time intervals, expressed in units smaller than seconds (many systems use milliseconds). We can convert delta milliseconds only to everything up to and including hours without knowledge of when the interval occurs, because everything larger has a variable length, therefore not all useful intervals can be specified in just milliseconds.
Arithmetic on intervals is trivial. To support arithmetic on calendar dates and civil times we can set epochs and provide a few fundamental conversions:
Just calculating one of milliseconds, seconds or days since epoch and then performing arithmetic on these intervals is not sufficient. Given an answer of 6.5 days between two times, is the later time the same week as the earlier? Is a time 24 hours from now always in the next civil day? It might NOT be on the day DLS springs forward, i.e. a 24 hour day. I hope you can see from the above that not all date calculations are just the same as arithmetic on intervals expressed in small enough units.
* Convert seconds-since-epoch to a civil time in the local time zone. * Convert any civil time to seconds-since-epoch. * Convert days-since-epoch to a calendar date. * Convert a calendar date to days-since-epoch.
What can often get you most of the answers to the above examples is the ability to: * Convert a calendar date or time to whole months, hours, weeks, years, quarters, moons, pay periods :-) etc. since epoch with or without considering TZ. and alternately or in addition depending on your tastes, its related cousin * Convert a time to the another time that represents the beginning of the period; i.e. beginning of year, month, week, day etc. with or without considering TZ. I think many of the people who are suggesting changes are considering some of the possibilities I have mentioned, but it seems ti me you may have simplified the problem somewhat and overlooked some of the interesting challenges of relative date calculations, comparisons and specification. -Paul
"D. J. Bernstein" wrote:
Paul Eggert writes:
I don't understand what problems you're trying to solve here.
Time libraries should be designed to support the features that real programs need. [....]
Robert E. Brown's query very concisely pointed out two fundamental problems with existing time libraries: thread safety, and performing conversions to and from multiple "local" time zones in a single program. Simulation and real-time programs, for instance in the financial arena, need to know about past, present, and future offsets and DST rules for locales all around the world. Nothing infuriates me more than seeing "US rules" hardcoded in some supposed timezone helper class; this is the whole reason the tz list exists. I'll grant you that there are not a lot of us who demand conversions to and from lots of "local" time zones, over spans of many years, in a single (possibly multi-threaded) performance-sensitive application. But these are "real programs". The calendar arithmetic issues Paul Hill brought up are another story altogether. Whether these should be part of a standard C library is debatable. I for one would favor a portable standalone implementation of xtime, timezone_t, etc. a la Kuhn & Eggert. Seems like that would be easier to maintain and port. Why expect so much of the OS vendor?
Scott Harrington wrote:
The calendar arithmetic issues Paul Hill brought up are another story altogether.
Whether these should be part of a standard C library is debatable. [...] Why expect so much of the OS vendor?
I'm not necessarily suggesting that the standard should include it. I only mention it because D.J. Bernstein seemed to over simplify the list of what needs to be done with times in programs while starting to build a case for a simplified lib. I would consider a library powerful enough if I could build the three parts mentioned on top of the standard libraries without repeating any of significant part of the data or calculations already contained in the libs. Those three parts are: * [Relative] Time intervals, expressed as combinations of unspecified [durations] of years, months, days, weeks, hours etc. * Convert a calendar date or time to whole months, hours, weeks, years, quarters, moons, pay periods :-) etc. since epoch with or without considering TZ. And alternately or in addition depending on your tastes, its related cousin: * Convert a time to the another time that represents the beginning of the period; i.e. beginning of year, month, week, day etc. with or without considering TZ. The second one seems like the key to other two, thus a possible candidate for inclusion in a standard library. I haven't read all of the proposals, so this is not a criticism of any of them, only a comment about what the areas of date/time could and might be. -paul
Here are easy answers to Paul Hill's date-calculation challenges using libtai's date functions. caldate_mjd() converts from a calendar date to the traditional MJD number, and caldate_frommjd() converts back. Paul Hill writes:
the beginning next week,
day = caldate_mjd(&cd); do caldate_frommjd(&cd,++day,&weekday,0); while (weekday != 0); /* there are faster ways to do this, of course */
the first day of this year,
cd.month = 1; cd.day = 1;
start of next month,
++cd.month; cd.day = 1; caldate_normalize(&cd); /* same as caldate_frommjd(&cd,caldate_mjd(&cd),0,0); */
two days before the beginning of the last month of the year,
cd.month = 12; cd.day = -1; caldate_normalize(&cd);
the last Thursday in November,
cd.month = 12; cd.day = 1; day = caldate_mjd(&cd); do caldate_frommjd(&cd,--day,&weekday,0); while (weekday != 4);
exactly 60 days from now,
caldate_frommjd(&cd,caldate_mjd(&cd) + 60,0,0);
exactly two months before now,
In my experience, as illustrated previously on this mailing list, people who use that phrase don't know what they're talking about. Try this: d = cd.day; cd.month -= 1; cd.day = 0; caldate_normalize(&cd); if (cd.day > d) cd.day = d; ---Dan
Date: Fri, 27 Aug 1999 19:55:35 -0700 From: Scott Harrington <seh4@ix.netcom.com> I for one would favor a portable standalone implementation of xtime, timezone_t, etc. a la Kuhn & Eggert. I'd love to see one too. :-) Unfortunately some of it would have to be system-dependent in a tricky way. I hope that most of it could be portable, though. Date: 28 Aug 1999 00:12:07 -0000 From: "D. J. Bernstein" <djb@cr.yp.to>
I don't understand what problems you're trying to solve here. Kuhn and I are trying to specify an improved API for time handling. As discussed in http://www.cl.cam.ac.uk/~mgk25/c-time/ section 2, the ISO C API is pretty lame. The decision about which features should make it into a new API are a delicate judgment call, of course. I've tried to synthesize the best ideas of Kuhn with some of your ideas, plus others. Of course there's room for improvement; it's still just a draft. Time libraries should be designed to support the features that real programs need. For example: * Benchmarking tools need to measure differences in real time. Consider the gettimeofday() function. Unfortunately, gettimeofday doesn't measure real time, at least not on my Solaris box. It measures the system's notion of the current time, and this can jump when root adjusts the clock. Kuhn's proposal and mine both let you measure real time even if root adjusts the clock. It's xtime_get(TIME_MONOTONIC|TIME_NOW) in my proposal. * Networking tools need to schedule events at moments in real time: e.g., send this packet 0.2 seconds after that one. Consider the select() and poll() functions. If you want a simple delay, then xtime_delay(N) will do; if you want some other primitive, e.g. wait for input on a file descriptor with a time out, then I'm afraid it's out of scope for a pure time API. * Clock programs need to know the current time in the local time zone. Consider the time() and localtime() functions. That corresponds to xt=xtime_get(TIME_SYSTEM|TIME_NOW) and xtime_breakup(&tm, xt, tz), where tz is the output of a previous call to tz_prep. (Perhaps xtime_breakup should default to local time instead of UTC; that would simplify things a bit in the common case.) * Mail readers, given a list of civil times from various time zones, need to sort the times into numerical order. Consider the mktime() function. Of course mktime can't do that, since it doesn't handle time zones. But xtime_make should be able to do it, since it accepts an object describing the clock and time zone in question. * Calendar programs need to know tomorrow's date, the number of days until next month, etc. I hadn't intended for the improved time API to address calendrical issues, but if there's a demand for this it could be added. * Convert seconds-since-epoch to a civil time in the local time zone. * Convert any civil time to seconds-since-epoch. These primitives are in both Kuhn's and my proposals. * Convert days-since-epoch to a calendar date. * Convert a calendar date to days-since-epoch. These aren't. Perhaps there should be an xdate_breakup and xdate_make. A more elegant possibility is to add a separate clock type or option for a clock that ticks once per day; one could then use xtime_breakup and xtime_make for calendar conversions. (Similarly for minutes, months, weeks, etc.) Let me think about it a bit more. http://www.twinsun.com/tz/timeapi.html adds the following primitives to your list. * Create a time zone object from a time zone specification. * Interrogate clock features, e.g. their resolution. * Interrogate time zone features, e.g. the next DST transition. * Fancy formatting, e.g. to get ISO date strings. * Delay for a specified interval. * Different kinds of clocks (e.g. TAI vs UTC vis realtime). * Conversion among these clocks, and time_t. * Report errors, e.g. clock unavailable. To some extent this spec is overkill; I'd certainly like to see a smaller one. (In my defense, I started from Kuhn's spec, which has even more goodies.) However, we must have the ability to handle multiple time zones simultaneously (e.g. the first additional primitive mentioned above). Multiple time zones are what started this thread, and many apps need them.
Paul Hill wrote on 1999-08-28 02:30 UTC:
I don't understand what problems you're trying to solve here.
Time libraries should be designed to support the features that real programs need. For example:
Your examples where perfectly good, but you left out some of the real fun calendar calculations.
There are two very different types of date/time libraries here, and we have to be careful not to mix up the two: A) Base functionality access to resources that cannot be accessed at the moment in a portable way (mainly: TAI, UTC, leap second announcements, centrally administrated geographic time zone information, operational status of TAI/UTC reference, etc.). B) Ultracomfortable handling of any sort of time, whatsoever, including various calendar systems, financial algorithms, historic dates, astronomical and clerical algorithms, etc. I feel that A) deserves to be standardized, because it is part of the information infrastructure that an operating system has to provide. Whether it becomes part of C, POSIX, or some other formal standard is more a political than a technical issue. The functionality of B) on the other hand can be implemented in a fully portable way in C already today. You have the base functionality of integer arithmetic, on top of which you can build whatever date and calendar classes you feel like. I do not think that there is a real need to standardize these at all, just like there is no real need to standardize interfaces to linear algebra packages. A single high-quality portable freeware implementation is all that is needed to keep us happy. Especially note, that there is no reason that A) and B) have to use the same data types. It is only necessary that B) understands the data types of A). I am often puzzled to hear people expect, that the data format that comes out of the real-time clock interface has to accommodate for times back to the big bang, even though this will hardly ever be necessary in practice unless we make significant and amazing breakthroughs in physics. There are many good reasons, why a base mechanism should be built around fixed-point arithmetic (the clock's resolution doesn't change of time, so why shift a comma?), while a comfortable calendar algorithm system could be better build around floating point numbers, for instance (who needs nanosecond precision time back in 25000 B.C?). My and Paul's proposal very clearly restrict themselves to the scope of A), that is they want to provide in a portable way access to infrastructure information that is otherwise not accessible. These proposals want to replace gettimeofday() such that the kernel or time daemon in the OS provides a richer menue of information for the application to choose from, plus they want to provide sufficiently flexible read access to a timezone database. Dan's libtai on the other hand (as I understood it) targets more towards B), i.e. it sits on top of the existing gettimeofday() base mechanism, and it tries to make a best-effort conversion of what gettimeofday() provides (with all its inherent limitations, e.g. undefined behavious during leap seconds) into a format that is more suitable and easier to handle for certain types of applications, most notably those where leap seconds are undesired effects and that care more about accurate interval measurements than an accurate and reliable relationship to the civilian time notations. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Paul Eggert writes:
Kuhn and I are trying to specify an improved API for time handling.
That doesn't answer the question. What problems are you trying to solve? How exactly is each of your API features used in real programs?
I hadn't intended for the improved time API to address calendrical issues, but if there's a demand for this it could be added.
Civil-time conversions make essential use of basic calendar functions. It's silly to hide these functions.
Unfortunately, gettimeofday doesn't measure real time, at least not on my Solaris box. It measures the system's notion of the current time, and this can jump when root adjusts the clock.
Time for a reality check. The OS stores a single ``last modification'' timestamp for each file. These timestamps are compared by the ``make'' file-construction tool. If root sets the clock backwards, ``make'' can produce disastrously incorrect results. This is one of the reasons that your Solaris box has an adjtime() syscall that makes a gradual adjustment without screwing up monotonicity.
However, we must have the ability to handle multiple time zones simultaneously
I agree that the basic convert-to-civil-time function should allow a zone argument. ---Dan
libtai isn't an abstract ``improve the C time API'' thought experiment. It's a collection of time routines that I'm using in several programs. libtai started as a pair of fast routines to convert seconds-since-epoch to RFC 822 year-month-day-hour-minute-second-gmtoff timestamps and back. Typical time.h implementations used an absurdly slow binary search for mktime(), frittered away several pages of memory per process, and didn't have any sane way for mktime() to deal with gmtoff. libtai grew when I started fixing Y2038 bugs. I'm not worried about time_t, which will eventually be extended to 64 bits; I'm worried about 4-byte timestamps in inodes and tar files and other databases. So I wrote some routines to manipulate a simple, portable 8-byte timestamp format with 1-second precision, and a high-precision 16-byte extension. The reason that I'm skeptical about the complicated vaporware proposals is that libtai has already proven adequate for a variety of tasks: * Synchronizing the local clock using SNTP. * Recording precise timestamps in system logs. * Scheduling a torrent of network events. * Handling email timestamps. (See mess822 or the next qmail release.) My clock ticks monotonically in real time from a particular epoch. I don't need TIME_MONOTONIC and TIME_TAI and TIME_SYSTEM; they're all the same thing. Nowhere is there any use of the fundamentally broken time scales TIME_LOCAL and (deceptively named) TIME_UTC. I'm not saying that libtai 0.60 is a complete replacement for time.h. In particular, it doesn't generate civil times in zones other than UTC; if you want to display a local clock then you have to call localtime(). Markus Kuhn writes:
I am often puzzled to hear people expect, that the data format that comes out of the real-time clock interface has to accommodate for times back to the big bang,
You misunderstand. That's merely a side effect of changing time_t from 32 bits to 64 bits so that it handles dates in the foreseeable future. ---Dan
"D. J. Bernstein" wrote:
Here are easy answers to Paul Hill's date-calculation challenges using libtai's date functions. caldate_mjd() converts from a calendar date to the traditional MJD number, and caldate_frommjd() converts back.
I hope that is with or without consideration for local TZ. I'll assume that is what the last argument is for in caldate_frommjd(). BTW, is there some description of your API on the WWW somewhere?
exactly two months before now,
In my experience, as illustrated previously on this mailing list, people who use that phrase don't know what they're talking about.
Why is that? I was just listing examples, but I see you are already into insults; can we keep it civilized please? (At least hedge your bets by using the phrase "most people") The question is what does the person who request that particular value want it for and is it actually useful in their application. You will notice I listed it "after 60 days from now", hopefully you saw that as a contrast to variable lengths months which you took into consideration. Since you think people do mess it up, all the more reason to include such things in some library somewhere. Now that library could be a second level on top of one of the various proposals we see here. Yet, it is just such clerical time-keeping curiosities which I have found need to be quick to do with any base library. It is the need to ask questions about the calendar that is in the base libraries that causes me to see weaknesses in some APIs (I see that Paul E. has already responded that maybe exposing some of that info might be a good service.)
the last Thursday in November,
cd.month = 12; cd.day = 1; day = caldate_mjd(&cd); do caldate_frommjd(&cd,--day,&weekday,0); while (weekday != 4);
Why does the weekday stumble out some "side door" and is not part of the standard data structure? I would expect someone who extends a standard library to extend the standard structure and just add more to it, i.e. adding business quarters, fiscal years, fiscal months, pay periods or whatever, to the end of a better tm struct (like tm from http://www.cl.cam.ac.uk/~mgk25/c-time/) What is so special about day of week? I'm underwhelmed by the need when using your API to put together and take apart a MJD and all fields, once for each day just to walk back to a nearby weekday. An alternative API _might_ provide a set of fields (again like tm in Markus' and Paul E's API) that could include day of week and week of month and then be willing to figure the MJD from whatever is provided. I'll admit most of the worst relatative dates calculations can be figured out slowly and then remembered as MJD or a date/time, but not all. I would also hope that that any header file would define SUNDAY, MONDAY, TUESDAY etc. so I don't have to know the convention, even if there is an ISO standard. The same applies for the months: JANUARY, FEBRUARY etc. -Paul
Paul Hill writes:
BTW, is there some description of your API on the WWW somewhere?
The code is freely available from http://pobox.com/~djb/libtai.html. I've started putting up API pages for the next release; in particular, http://pobox.com/~djb/libtai/caldate.html is done.
An alternative API _might_ provide a set of fields (again like tm in Markus' and Paul E's API) that could include day of week and week of month and then be willing to figure the MJD from whatever is provided.
Who cares? Remember that the point of libtai is to support real programs, not to build an API in the sky.
I would also hope that that any header file would define SUNDAY, MONDAY, TUESDAY etc. so I don't have to know the convention, even if there is an ISO standard.
Why would a program want to refer to specific weekdays, rather than having a table of all the weekdays?
I hope that is with or without consideration for local TZ.
What are you talking about? The Gregorian calendar does not depend on your local time zone.
I'm underwhelmed by the need when using your API to put together and take apart a MJD and all fields, once for each day just to walk back to a nearby weekday.
This need is a figment of your imagination. The reason I wrote ``there are faster ways to do this, of course'' was to forestall this pointless discussion. ---Dan
From: "D. J. Bernstein" <djb@cr.yp.to> Date: 28 Aug 1999 09:00:27 -0000 Paul Eggert writes:
Kuhn and I are trying to specify an improved API for time handling.
That doesn't answer the question. What problems are you trying to solve? How exactly is each of your API features used in real programs? Justifying each feature of the API in detail would take some time. Admittedly the rationale should be improved to do this. The big picture: my main motivation is better support for time zones, for programs like xtide (or the application that started this thread). Kuhn is also motivated by the need for more precise characterization of clocks.
Unfortunately, gettimeofday doesn't measure real time, at least not on my Solaris box. It measures the system's notion of the current time, and this can jump when root adjusts the clock.
... If root sets the clock backwards, ``make'' can produce disastrously incorrect results. This is one of the reasons that your Solaris box has an adjtime() syscall that makes a gradual adjustment without screwing up monotonicity. True, but (1) in practice many people set the clock directly, without using adjtime, and (2) even adjtime can mess up benchmarks, the application domain that you proposed gettimeofday for. With gettimeofday, one must make sure that nobody adjusts the system's notion of the time of day while you're doing benchmarks. With TIME_MONOTONIC, you needn't worry about adjustments to the system clock. I agree that my proposed API is still too complicated. When I get the time I'll try to simplify it. Your code is a valuable resource in this area: implementation experience counts for a lot in my book.
Paul Eggert wrote on 1999-08-29 11:04 UTC:
True, but (1) in practice many people set the clock directly, without using adjtime, and (2) even adjtime can mess up benchmarks, the application domain that you proposed gettimeofday for. With gettimeofday, one must make sure that nobody adjusts the system's notion of the time of day while you're doing benchmarks. With TIME_MONOTONIC, you needn't worry about adjustments to the system clock.
The guaranteed continuity of TIME_MONOTONIC is one reason for the existence of this separate clock type. This property is a very welcome (and sometimes formally required!) assurance for the designer of safety-critical system, who is not allowed to assume that the real-world user knows, which type of resetting the clock is legal and which is not. Embedded systems are in the real world often operated accidentally with dates that are years off, and when people find out, they want to be able to fix this immediately, without messing up safety-critical processes while doing so. You all should have heard by know about the various near-catastrophes that dumb Y2K tests have caused because the software was not prepared to handle non-monotonicity. There definitely is a requirement for at leat two clock types, one guaranteed to run always and freely, the other providing a best-effort approximation of an external scale such as say UTC, TAI, or whatever the available local time happens to be. But that is not all. A second reason are small embedded systems (industrial automation controllers (e.g., chemical and pharmaceutical industry) are frequently quoted examples) that have no battery-powered clock and that get their first opportunity to sync with an external time scale (if at all) only considerable time after they booted. There are safety critical applications that need guaranteed precise relative interval timing right after system start-up, no matter whether the GPS antenna happens to be pointing in the right direction etc., and TIME_MONOTONIC is intended for these as well. This was an industrial requirement documented in the POSIX process when the POSIX real-time extensions group considered revising the clock definition to something not to far away from my xtime_get. And yes, these are real world safety and security requirements in embedded realtime systems, in which the C API is very widely used today, and where it is far from being satisfactory. Not every large-scale C implementation underlies assumptions that might be perfectly valid for Dan's desktop workstation. "D. J. Bernstein" <djb@cr.yp.to> wrote on 1999-08-29:
Who cares? Remember that the point of libtai is to support real programs, not to build an API in the sky.
Dan, did you ever work with an FAA certified run-time library and are you familiar with the requirements expected from clock APIs in such environments? I get the impression that you could learn a *lot* from building "an API in the sky" ... http://www.cl.cam.ac.uk/~mgk25/c-time/ Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Dan and Scott, "D. J. Bernstein" wrote:
An alternative API _might_
Who cares? Remember that the point of libtai is to support real programs, not to build an API in the sky.
I figure that I need an API that: (1) cleanly calculates all the parts of the date and time it knows about, (2) could be reasonably extended or leveraged to cover the "clerical curiosities" of keeping and calculating values related to dates and times. While this could lead to API in the sky, it is also worth considering the possibilities even for the core API that any API in the sky uses.
I would also hope that that any header file would define SUNDAY, MONDAY, TUESDAY etc. so I don't have to know the convention, even if there is an ISO standard.
Why would a program want to refer to specific weekdays, rather than having a table of all the weekdays?
A Table? For what? This is a comment about your code using "magic numbers", that is all. If you provide a header that defines SUNDAY, I don't need to know or care and any maintenance programmer doesn't need to know or care whether the usage in your code is SUNDAY=0 or SUNDAY=1, or SUNDAY=7.
I hope that is with or without consideration for local TZ.
What are you talking about? The Gregorian calendar does not depend on your local time zone.
Sorry, my mistake, I'm so used to thinking about date and time together. In such cases TZ does matter. Scott Harrington wrote:
Simulation and real-time programs, for instance in the financial arena, need to know about past, present, and future offsets and DST rules for locales all around the world. Nothing infuriates me more than seeing "US rules" hardcoded in some supposed timezone helper class; this is the whole reason the tz list exists.
I'll grant you that there are not a lot of us who demand conversions to and from lots of "local" time zones, over spans of many years, in a single (possibly multi-threaded) performance-sensitive application. But these are "real programs".
Allow me to suggest a scenerio which just needs the latest TZ/DLS changes, but may be more common than just "simulation and real-time". My experience suggests that as more organizations cover more than one timezone and more business is done in a cooperative manner between some branch office and come central location, there is more need to make sure every processs knows the correct and same TZ rules for all TZs involved in any of the data. Consider for example, a multithreaded server at some corporate central location that is taking information from remote locations each night after closing time (client local time). Also consider that not all uses of dates and times can be converted to server time, client time, UTC time; there can be a mix of all of them. Therefore this rather pedestrian example of a corporate server taking remote data would want to be able know all the TZs it is dealing with well, and be able to handle them in a multi-threaded environment. Plus the client (branch office) machine also might need to deal with date and time conversions between various zone depending on what it was sending. Even if it was not doing these date conversions in a multi-threaded or real-time environment. I only give this example to show that there is plenty of need in ordinary information processing applications for good TZ based date/time calculations in a multi-threaded environment. cheers, -Paul
participants (6)
-
D. J. Bernstein -
Markus Kuhn -
Olson, Arthur David (NCI) -
Paul Eggert -
Paul Hill -
Scott Harrington