This document is still under construction
|
Additional Constraints on time_t
By David R. Tribble
Revision: Draft 1, 2001-02-13
|
This document is still under construction
Document Number: WG14 N___/X3J11 __-___
C200X Revision Proposal
=======================
Title: Additional Constraints on time_t
Author: David R. Tribble
Author Affiliation: Self
Postal Address: #################
Plano, TX ##########
USA
E-mail Address: david@tribble.com
Web URL: http://david.tribble.com
Telephone Number: +1 972 943 5125 (15:00-00:00 Z)
+1 ############ (00:00-03:00 Z)
Fax Number: +1 972 943 5111
Sponsor: ________________________________________
Revision: Draft 0
Date: 2001-02-13
Supersedes: None
Proposal Category:
X_ Editorial change/non-normative contribution
__ Correction
__ New feature
__ Addition to obsolescent feature list
__ Addition to Future Directions
__ Other (please specify) _____________________________
Area of Standard Affected:
__ Environment
__ Language
__ Preprocessor
X_ Library
X_ Macro/typedef/tag name
__ Function
X_ Header
__ Other (please specify) _____________________________
Prior Art: No specific implementation.
Target Audience: C programmers.
Related Documents (if any): None
Proposal Attached: X_ Yes __ No, but what's your interest?
Abstract:
The addition of contraints on the behavior of the time_t type as defined
in the <time.h> standard header.
|
The original proposal as posted on the newsgroup:
Subject: Re: time_t constraints
Date: Tue, 13 Feb 2001 19:07:00 -0600
From: David R Tribble <david@tribble.com>
Organization: BEA Systems, Inc.
Newsgroups: comp.std.c
I suggest the following list of new constraints for the 'time_t' type
(or possibly some new "extended time" type):
1. Arithmetic type.
The 'time_t' type has arithmetic type.
(This is unchanged from the current requirements. It is broad
enough to allow time_t to be an integer or floating-point type,
but also too broad, allowing weird types such as 'complex long
double' and 'imaginary float'.)
(I think that mandating that time_t be a integer type might cause
some existing conforming implementations to become nonconforming,
but I'm not sure. Does anyone know of an example? IIRC, the Apple
Rhapsody OS had an 'NSDate' class type that used a 'double' as
a seconds counter; I don't know what type its 'time_t' was.)
2. Monotonically increasing.
'time_t' values increase throughout time, i.e., the time_t value
for one event is arithmetically less than the time_t value for
an event occurring later in time (within the implementation's
"epoch").
3. Comparisons.
Two 'time_t' values may be compared; if they compare equal, they
represent identical moments in time; if one compares less than the
other, it represents a moment in time that occurs before the moment
represented by the greater value (within the implementation's
"epoch").
In addition, the following new macros should be added to the <time.h>
header:
_TIME_SUPPORTED
Has integer type, and evaluates to a nonzero (true) value if the
'time_t' type of the implementation conforms to the constraints
above; otherwise it evaluates to zero (false).
_TICKS_PER_SEC
Specifies the minimum number of distinct "ticks" per second that
the 'time_t' type is capable of representing uniquely within its
"epoch". This must be at least 1.
(If 'time_t' is an integer type, this is the exact number of ticks
per second that it can represent uniquely. If 'time_t' is a
floating-point type, this is the largest resolution representable
within its epoch; time values outside this epoch may have different
resolutions.)
(The term "epoch" is a little vague, and should probably have a
formal definition.)
_TIME_MIN
Has type 'time_t', and specifies the minimum 'time_t' value that
represents a meaningful time within the "epoch". All 'time_t'
values representing meaningful times must not compare less than
this value.
(This therefore represents the first "valid" date in the epoch.)
_TIME_MAX
Has type 'time_t', and specifies the maximum 'time_t' value that
represents a meaningful time within the "epoch". All 'time_t'
values representing meaningful times must not compare greater than
this value.
(This therefore represents the last "valid" date in the epoch.)
_TIME_UNKNOWN
Has type 'time_t', and specifies an arbitrary date outside the
"epoch", which can be used to indicate an unknown or indeterminate
date. This value must not compare equal to any 'time_t' value
that represents a meaningful time within the "epoch".
(This is intended to be used for initializing time_t variables,
and as a possible function return value indicating that an error
or inconsistency has occurred, such as during a calendar date
conversion routine. This is meant to replace the current use of
'(time_t)(-1)' as an error indicator, since -1 might represent a
valid time within the epoch.)
_TIME_IS_INTEGER
Has integer type, and evaluates to a nonzero (true) value if the
'time_t' is an integer type; it evaluates to zero (false) for all
other types.
(This allows for detecting implementations where 'time_t' is a
floating-point type.)
_TIME_IS_LINEAR
Has integer type, and evaluates to a nonzero (true) value if the
'time_t' is implemented in such a way that adding 1 (i.e., one
tick) to a given time_t value results in a new time_t value that
represents a moment occurring exactly one tick after the moment
represented by the old value.
(This allows for implementations where time_t is a simple integer
tick count, as well as though that map clock ticks into alternate
time_t forms, e.g., concatenated bitfields, such as
<2001:05:08:02:30:00:500>.)
_TIME_HAS_LEAP_SECS
Has integer type, and evaluates to a nonzero (true) value if the
'time_t' representation properly represents leap seconds;
otherwise, it is zero (false).
I also considered adding these macro constants, but decided that they
would be tied to a particular calendar, and thus are unsuitable for
use with a calendar-independent time_t type:
_TIME_YEAR_MIN (not needed)
Specifies the minimum year number that can be entirely represented
by a 'time_t' value (i.e., this is the first whole year of the
"epoch" represented by the 'time_t' type.)
_TIME_YEAR_MAX (not needed)
Specifies the maximum year number that can be entirely represented
by a 'time_t' value (i.e., this is the last whole year of the
"epoch" represented by the 'time_t' type.)
Comments?
-
David R. Tribble, david@tribble.com, http://david.tribble.com
Last modified: Thu Feb 22 10:38:30 CST 2001