Re: [LEAPSECS] ] Fractional US civil time period representation is brittle
Notice that I have not specified that the actual syscall must use FP, the conversion from 64.64 to FP could, and probably should, happen in libc. That means somebody could implement this now with current POSIX kernel support and see how well it works. -- My proposed API does not solve all imaginable problems relating to time, in particular it does not solve the programmer is clueless about time problem, but it does try to make it easier for programmers to do things right, than for them to make mistakes. I think it would be a big help if the documentation had a section describing the not-so-obvious parts of time. Are they all associated with leap seconds? How about leap years? (a year from today gets interesting) Perhaps it should go in a separate man page listed in the SEE ALSO pages of time commands. --- Has anybody made a list of routines that take time as a parameter? sleep, usleep, select... --- Testing for equality of timestamps? I would hope that using a FP format and mandate that for runtime you never get two which are the same, should eliminate that hobby. They might be equal if generated on two different systems. Even if we only have one system, I'm not sure I want a simple concept like get-the-current-time to require a lock on multicpu or multicore systems. -- You can create any UTC timestamp you want at any point in history where it is defined. But you can only convert that UTC timestamp to a realtime_t (and vice-versa) for timestamps where the conversion is defined. UTC is only defined approximately 6 months in advance, and that is an interesting point for implementors of this API. I think a useful system needs a way to say a year from now, or next Dec 25. -- One of the problems right now with the 'right' database is that you have to update it and already running programs don't notice this update since it would be prohibitively expensive to do a stat call on each time operation. Any clever ideas around this issue? 2 suggestions (we can debate the clever part): Poll once per day. Kick the program with a signal similar to what happens when log files get rotated, or piggyback on the same signal. -- These are my opinions, not necessarily my employer's. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] ] Fractional US civil time period representation is brittle
Consider US eastern daylight time, June 30, 2012. 1/2 hour for the first hour of the day is 1800.0 SI seconds. 1/2 hour for the 19th hour of the day is 1800.5 SI seconds. 1/2 minute for the 1st minute of the day is 30.0 seconds. 1/2 minute for the 1139th minute of the day is 30.5 seconds. This will make certain time computations quite intricate. Representing the time as a simple floating point number may lead to unexpected results. Gerard Ashton ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ] Fractional US civil time period representation is brittle
In message 4f1ac413.1010...@comcast.net, Gerard Ashton writes:
Consider US eastern daylight time, June 30, 2012.
[...]
This will make certain time computations quite intricate.
Representing the time as a simple floating point number may
lead to unexpected results.
If this is with reference to my REAL proposal, there is a fundamental
misunderstanding involved.
Only the TAI(-estimate) timestamp will be represented by a floating
point value.
All other timescales, including UTC, will be derived from this
floating point value and represented in a suitable form for that
timescale.
For instance a MJD timestamp _may_ be represented by a float, but
UTC and most forms of civil/legal/local time would be represented
with the struct tm:
struct tm {
double tm_fraction;/* fractional part of second */
int tm_sec; /* seconds after the minute [0-60] */
int tm_min; /* minutes after the hour [0-59] */
int tm_hour;/* hours since midnight [0-23] */
int tm_mday;/* day of the month [1-31] */
int tm_mon; /* months since January [0-11] */
int tm_year;/* years since 1900 */
int tm_wday;/* days since Sunday [0-6] */
int tm_yday;/* days since January 1 [0-365] */
int tm_isdst; /* Daylight Savings Time flag */
longtm_gmtoff; /* offset from UTC in seconds */
char*tm_zone; /* timezone abbreviation */
};
--
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] ] Fractional US civil time period representation is brittle
On 1/21/2012 9:13 AM, Poul-Henning Kamp wrote:
In message4f1ac413.1010...@comcast.net, Gerard Ashton writes:
Consider US eastern daylight time, June 30, 2012.
[...]
This will make certain time computations quite intricate.
Representing the time as a simple floating point number may
lead to unexpected results.
If this is with reference to my REAL proposal, there is a fundamental
misunderstanding involved.
Only the TAI(-estimate) timestamp will be represented by a floating
point value.
All other timescales, including UTC, will be derived from this
floating point value and represented in a suitable form for that
timescale.
For instance a MJD timestamp _may_ be represented by a float, but
UTC and most forms of civil/legal/local time would be represented
with the struct tm:
struct tm {
double tm_fraction;/* fractional part of second */
int tm_sec; /* seconds after the minute [0-60] */
int tm_min; /* minutes after the hour [0-59] */
int tm_hour;/* hours since midnight [0-23] */
int tm_mday;/* day of the month [1-31] */
int tm_mon; /* months since January [0-11] */
int tm_year;/* years since 1900 */
int tm_wday;/* days since Sunday [0-6] */
int tm_yday;/* days since January 1 [0-365] */
int tm_isdst; /* Daylight Savings Time flag */
longtm_gmtoff; /* offset from UTC in seconds */
char*tm_zone; /* timezone abbreviation */
};
The REAL proposal appears to include the necessary tools (when fleshed
out) but it would be
easy to misapply the tools, for example, by supposing that 1/2 UTC day
is the same duration
as 1/2 EDT day. This isn't a criticism of the idea, just an observation
on how easy it is to
go astray.
Gerard Ashton
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ] Fractional US civil time period representation is brittle
In message 4f1accfc.2010...@comcast.net, Gerard Ashton writes: The REAL proposal appears to include the necessary tools (when fleshed out) but it would be easy to misapply the tools, [...] Fiskars once won in court, arguing that people who use tools incorrectly is not their responsiblity as a maker of chain-saws. I'm going to make the same argument: My proposed API does not solve all imaginable problems relating to time, in particular it does not solve the programmer is clueless about time problem, but it does try to make it easier for programmers to do things right, than for them to make mistakes. But it does solve the problem that you cannot ask the operating system what time it is. -- 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
