I don't know how many on this list program or not in C, so here is some background that may assist....
There are three POSIX functions which convert between broken down time format (aka YYYY-MM-DD HH:MM:SS) to a seconds-since-1970 scalar value. They are gmtime(), localtime(), and mktime() gmtime() converts seconds to broken down time in terms of zero hours offset from greenwich. localtime() converts seconds to broken down time in terms of the local timezone. (Obviously the most commonly used of the functions) mktime() is the inverse of localtime(). There is no fourth function to do the inverse of gmtime(). For this and other reasons many programs implement their own function to do this. They would assume 86400 seconds per day to copy POSIX or because they have never heard of leap seconds. I would guess there are an enormous number of statically linked executables that contain such code. At this "late" stage in Unix software evolution the genie is out of the bottle. You can change the standard to whatever you like, but I guess few would comply. POSIX time (as implemented) does not conform to any time standard, and explains this in section "A.4.14 Seconds Since the Epoch". Unfortunately, this section is in the Rationale part of POSIX 3, so few people would ever look at it. In the "General Concepts" section it just says that there are 86400 seconds in every day. POSIX mentions UTC *only* to explain the general sense of POSIX's meaning: i.e. the general sense of counting seconds from 1970 rather than some other date like 1900. POSIX time has now evolved by consensus to (usually) mean: "we tick over with TAI, except on a leap second where we pause for one full second". And software is usually written to be robust enough to deal with the pause. The NTP server performs this pause. I don't think this consensus is defined in any standard. Anyone? I think A.4.14 has been posted before, but it is such gorgeous poetry I can't help posting it again. Kudus to the POSIX authors for their pragmatic attitude. FWIW, in spite of all of this, I myself favor the continued broadcast of leap seconds. ----- A.4.14 Seconds Since the Epoch [...] The topic of whether seconds since the Epoch should account for leap seconds has been debated on a number of occasions, and each time consensus was reached (with acknowledged dissent each time) that the majority of users are best served by treating all days identically. (That is, the majority of applications were judged to assume a single length-as measured in seconds since the Epoch-for all days. Thus, leap seconds are not applied to seconds since the Epoch.) Those applications which do care about leap seconds can determine how to handle them in whatever way those applications feel is best. This was particularly emphasized because there was disagreement about what the best way of handling leap seconds might be. It is a practical impossibility to mandate that a conforming implementation must have a fixed relationship to any particular official clock (consider isolated systems, or systems performing "reruns" by setting the clock to some arbitrary time). Note that as a practical consequence of this, the length of a second as measured by some external standard is not specified. This unspecified second is nominally equal to an International System (SI) second in duration. Applications must be matched to a system that provides the particular handling of external time in the way required by the application. ----- -paul _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
