[LEAPSECS] ] Fractional US civil time period representation is brittle
Gerard Ashton
ashtongj at comcast.net
Sat Jan 21 09:34:36 EST 2012
On 1/21/2012 9:13 AM, Poul-Henning Kamp wrote:
> 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 */
> };
>
>
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
More information about the LEAPSECS
mailing list