[LEAPSECS] ] Fractional US civil time period representation is brittle

[Poul-Henning Kamp]

In message <4F1AC413.1010802 at 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 */
        long    tm_gmtoff;      /* offset from UTC in seconds */
        char    *tm_zone;       /* timezone abbreviation */
};


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.