Additional Constraints on time_t
By David R. Tribble
Revision: Draft 1, 20010213

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 Email Address: david@tribble.com Web URL: http://david.tribble.com Telephone Number: +1 972 943 5125 (15:0000:00 Z) +1 ############ (00:0003:00 Z) Fax Number: +1 972 943 5111 Sponsor: ________________________________________ Revision: Draft 0 Date: 20010213 Supersedes: None Proposal Category: X_ Editorial change/nonnormative 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 floatingpoint 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 floatingpoint 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 floatingpoint 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 calendarindependent 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
Email comments to the author at:
david@tribble.com
The author's home page is at:
http://david.tribble.com.
Last modified: Thu Feb 22 10:38:30 CST 2001