In message <[email protected]>, 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 */
long tm_gmtoff; /* offset from UTC in seconds */
char *tm_zone; /* timezone abbreviation */
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email protected] | 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
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
