With all the discussion about POSIX time again, I present for contrast how time_t is defined on Non-POSIX UNIX systems. Here is the man page:
.\" @(#)unixtime.7 1.2 (IFCTF) 2013/01/19 .\" .hw time-stamp .TH UNIXTIME 7 "January 19, 2013" .UC 8 .SH NAME time_t \- representation of time in UNIX .SH DESCRIPTION ``Everyone'' knows that UNIX represents civil time (that is, time intended for display to casual human users) internally as a linear count of seconds since Zulu midnight, January 1, A.D. 1970, i.e., since \%1970-01-01T00:00:00Z. But does this ``Zulu'' mean GMT (a natural phenomenon whose meaning is independent of human whim) or UTC (a man-made political construct)? And does ``seconds'' mean counts of periods of radiation emitted by Cesium atoms, 1/86400th fractions of naturally-occurring cycles of day and night, or the rotation of the hands of some ``official civil time'' clock by a certain angle? .SH HISTORY As a matter of historical precedent, it is absolutely certain that in the early days of UNIX, computer clocks were set from wall clocks or wristwatches, \fInot\fP the other way around. Therefore, whatever abstract philosophical definition the Founding Fathers of UNIX may have had in mind, the meaning of .B time_t was defined .I de facto by the broken-down-time algorithm implemented in the .IR ctime (3) family of functions and its inverse implemented in the .IR date (1) command. In other words, the de facto meaning of .B time_t is whatever number results when the operator looks at a wall clock or wristwatch and enters the observed local civil time into .IR date . .PP The original .I de facto definition of .B time_t can thus be formally stated as follows: .IP 1. It is the rotation angle of the hands of a non-DST-observing civil time clock, i.e., time-of-day rather than physical time interval. .IP 2. One count of .B time_t represents an interval of civil time during which the hour hand of an official civil time clock rotates by 30 arc-seconds, while the minute hand of the same clock rotates by 6 arc-minutes, \fBcompletely irrespective of what this time interval may happen to equal in SI seconds.\fP .IP 3. The .B time_t epoch is the moment when the official civil time clocks at Murray Hill, New Jersey displayed \%1969-12-31T19:00:00 exactly, \fBcompletely irrespective of what this moment may correspond to on more formally defined timescales.\fP .SH CONTROVERSY Being merely a representation of civil time that has an uncertainty on the order of seconds and is completely meaningless on even finer scales, the traditional UNIX time is clearly unsuitable for applications that require time in a Newtonian or Einsteinian physical sense, such as physics experiments, air traffic control, etc. .PP In the opinion of Michael Spacefalcon, the maintainer of 4.3BSD-Quasijarus and the author of this manual page, the least invasive and least disruptive way to solve that problem would be to implement an entirely separate timekeeping system for physical interval time, entirely disconnected from traditional UNIX time, keeping the latter strictly for \fIcivil\fP (or social) purposes for which it has been predominantly used. .PP Unfortunately, a strong technocratic lobby has been relentlessly pushing in a different direction: they assert that the counts of .B time_t should be SI seconds, rather than seconds of mean solar time (1/86400th fractions of a day) whose duration in Newtonian physical time is variable and somewhat unpredictable thanks to the irregularities in Earth's rotation, and they demand that ``POSIX'' time be defined in terms of UTC, which is very problematic because the latter is a purely man-made construct that is highly susceptible to political machinations. .PP A commonly heard proposal is to switch .B time_t to a linear count of SI seconds, or more precisely, a count of SI seconds .I as reckoned by the technocratic cartel's worldwide ensemble of atomic clocks (never mind that such a count would instantly become devoid of all meaning if those clocks were all powered off for just a couple of minutes), and to produce time for human display (at least for those users who operate in jurisdictions that still use Mean Solar Time as the basis of their legal time, even if it's indirect MST in the form of UTC with leap seconds) by having .IR ctime (3) or other similar functions perform leap second manipulations. .PP At first glance the above proposal sounds like a good idea, and I have seriously considered it at one time as well. After all, given that MST is not directly and continuously observable, the most expedient method of producing a practical realization thereof that is continuously accessible in real time is to derive it algorithmically from a stable interval time source such as an atomic clock. If in today's society the approximation to Mean Solar Time that serves as most people's civil time is algorithmically derived from stable interval time, wouldn't it make more sense to adopt the latter as the fundamental basis of time for computers, and to synthesize the MST-approximation locally as needed? .PP Deeper thought, however, reveals the following problems with the proposal: .IP \(bu Terrestrial Time (TT), the most philosophically perfect (Platonic ideal) form of physical interval time on Earth, is in fact just as unattainable as the Platonic ideal form of Mean Solar Time. Therefore, attempting to build a system that runs on ``true physical time'' would in fact produce a system dependent on the .I human civilisation's consensus idea of true physical time, or even more precisely, .I a technocratic cartel's idea of true physical time. .IP \& Therefore, if we ever have to make a complete breakaway from the mainstream civilisation such that we lose access to all means of dissemination of ``consensus atomic time'', or if that consensus and its corresponding means of dissemination shift (either instantly or gradually) to something that we find completely unusable for whatever reason, all our efforts to maintain a notion of ``true physical time'' on our UNIX systems would be suddenly brought to naught. .IP \& On the other hand, recovery of an approximation to Mean Solar Time by an infrastructurally-deprived observer ought to be much easier than, for example, recovery of an approximation to TT using observation of various bodies of the solar system and fitting their positions into dynamical models. A form of solar time (mean or otherwise) would also most likely be of much more immediate benefit to a breakaway colony seeking to rebuild civilisation than a system of less tangible dynamical time. .IP \(bu Putting it another way, GMT, being a natural phenomenon, is more durable than UTC, a man-made construct whose survival is totally dependent on continuous, unbroken operation of very complex equipment with worldwide cooperation, and which is subject to political whim. If all humans were to kill each other off, UTC would cease to exist, and the same would happen if a new world war put an end to the notions of international cooperation. However, GMT would still be perfectly meaningful as the Mean Solar Time at the site of the ruins of Greenwich. .IP \(bu Assuming that the UNIX systems in question primarily serve the needs of human users whose civil time is a form of MST, we can take it for granted that every UNIX system will always need to be able to display MST-based civil times on demand, whether we like it or not, whether it be done by using MST as the ``native'' internal timescale, or by computing MST from a TT-approximating internal timescale on the fly. And since the ``real time'' reckoning requirements of the vast majority of applications are perfectly satisfied by the undisciplined off-the-shelf low-cost crystal oscillators that serve as standard computer system clocks, whose inherent instability (unpredictable frequency variations) exceeds the difference between TT and MST, it follows that a system clock that is steered to MST and reckoned in MST seconds is perfectly sufficient for the typical ``real time'' functions such as timing between retries, toggling DTR long enough for a modem to detect it, DNS zone refresh intervals, etc. .IP \& Therefore, it follows that an MST-modeling system clock is always needed, whereas an additional TT-modeling one is optional and very rarely needed. An ordinary UNIX system has absolutely no need for an interval time clock whose stability with respect to TT is greater than that of MST; hence the technocratic lobby's efforts to impose one upon us whether we want it or not are hereby rejected as unwelcome advances. .IP \& A system whose internal clock is maintained as a count of how many ``seconds'' total have been announced to the world by the technocratic cartel's ensemble of atomic clocks would have no practical use for this count except to convert it to an MST representation, be it a true angle measure or a pseudo-sexagesimal concoction of the 23:59:60 kind. Such a system would be burdened with the need to maintain up-to-date leap second tables, which are otherwise completely unnecessary, and worst of all, when those tables inevitably go stale, the result will likely be the opposite of the desired outcome: one would naively hope that the ``true atomic'' time in the kernel would remain correct with respect to TAI but the user display would be off by a second, alerting operators to the need to update their leap second tables, but the likely result is the opposite: if MST-based time forms as shown by wall clocks and wristwatches are seen as the ultimate authority on what the correct time is, ignorant operators will likely set the kernel time to the wrong value so that the user display would look ``right''. .IP \(bu ``If it ain't broke, don't fix it!'' The de facto definition of UNIX .B time_t that has existed up until now is a measure of Mean Solar Time: while the historical .I de facto definition is, more strictly speaking, a representation of .I civil time defined by local jurisdictions, rather than a more exalted scientific concept like MST, no jurisdiction (as of this writing) has yet defined its civil time to anything other than some form of MST, even if it's indirect MST in the form of UTC with leap seconds, hence the existing historical definition of .B time_t has, in fact, been MST in practice. This definition has served us very well all this time, it still works fine at the present, hence there is no need to change it now. .IP \& Any proposed switchover of .B time_t from a model of MST to a model of TT can only be done in two ways: either by instituting a retroactive redefinition and breaking the precise meaning of all historical timestamps, or by declaring some arbitrary numerical value of .B time_t to be the switchover point, such that values that are numerically lower are to be interpreted as MST, and those that are numerically higher as TT. The former method involves breakage of historical data for no gain; the latter method involves introducing additional complexity for no immediate benefit over status quo. .IP \& If we ever decide to make such a switchover in the future, doing it by the latter method at that future time would be no different conceptually from doing it now, hence there is no benefit to making the transition right now, and it makes more sense to maintain status quo until and unless a more compelling reason for change arises. .SH DECISION .IP \(bu The semantic meaning of .B time_t in 4.3BSD-Quasijarus is hereby defined to be a linear measure of elapsed Mean Solar Time on Earth in days, with each count of .BR time_t , hereby called a second, denoting 1/86400th of a day. .IP \(bu The timescale represented by .B time_t is hereby officially clarified to be .B GMT rather than UTC. .IP \(bu The SI definition of the second is hereby explicitly declared null and void for the purposes of timekeeping under 4.3BSD-Quasijarus, reverting to the original Sumerian definition of 1/86400th of a day. .SH "DIFFERENCE FROM POSIX" In .I de facto terms, the present UNIX definition of .B time_t is equivalent to what is colloquially known as ``POSIX time''. However, there are some important differences: .IP \(bu The POSIX definition of time makes references to ``UTC''. The Quasijarus definition, on the other hand, disavows all ties to UTC, explicitly and deliberately using GMT instead. .IP \(bu Because leap seconds are a special quirk of UTC that does not exist in GMT, no leap second handling issues are relevant to Quasijarus systems. Instead our system time is steered to an external source of astronomically observed Mean Solar Time via the .IR adjtime (2) system call. .IP \(bu The technocratic lobby that rallies under the banners of SI, UTC and POSIX derides the smoothed monotonic increase of system time at variable rates to account for the irregularities in Mean Solar Time relative to TT as being ``wrong''. I am not qualified to comment on whether such an approach is right or wrong in the POSIX world, but when it comes to Quasijarus systems, the present document authoritatively declares that the smoothed monotonic increase of system time at a slewed rate as produced by the .IR adjtime (2) system call .B is the most correct way to maintain the system's idea of civil Mean Solar Time. .PP In practical terms, for as long as UTC retains its leap seconds, and for as long as the systems claiming to follow POSIX continue to count the non-leap seconds of UTC, such that their .B time_t counts represent a measure of Mean Solar Time in reality, the POSIX and Quasijarus .B time_t timestamps will remain interoperable without error. However, the precise behaviour around a leap second will most likely differ: while Quasijarus systems are required to produce a smooth time ``smear'', most POSIX systems in this author's experience jump back in time and repeat a second instead. But the absolute time error between two systems, each implementing its respective ideal of time handling with absolute perfection, cannot exceed one second (one count of .BR time_t ), which should not be a problem for any reasonable civil or social application. .PP However, in the event that UTC is deleteriously redefined without leap seconds, such that it ceases to be a good-faith approximation to GMT, the explicit definition of Quasijarus system time as GMT rather than UTC will compel us to switch to some alternate realization of GMT, e.g., this author's proposed UTR system. And if the ``POSIX'' time count stops being a measure of MST and makes a switchover to being an approximation to some other time ideal such as TT (whether that happens by explicit action or implicitly as a result of a surreptitious change in some underlying reference like UTC or NTP), in the absence of Quasijarus making the same switchover decision explicitly, the POSIX and Quasijarus .B time_t timescales will begin to drift apart secularly. .SH RANGE LIMITS Completely separate from the question of philosophical semantics of the represented time is the issue of range limits imposed by the .B time_t data storage type. The original native type used for .B time_t has been the signed 32-bit .BR long , with the additional reinforcement that the original implementation of the .IR ctime (3) family of functions actually treated 32-bit values with the high bit set as negative, displaying years before 1970. The implications of this original .B time_t definition are: .IP \(bu All systems using this unchanged definition (or implementation, depending on one's point of view) are doomed to fail in early A.D. 2038 (year SE76 on the Terran Revolutionary Calendar) when the largest second count that can fit into 31 bits is reached: upon reaching the fateful count, the system will suddenly start displaying dates in late 1901. .IP \(bu The original definition and implementation allowed .B time_t values to represent proleptic timestamps between \%1901-12-13T20:45:52 and \%1969-12-31T23:59:59 GMT, inclusive. However, no such timestamps exist in any of the releases from BTL or Berkeley, and no such timestamps have been created at Harhan either, as I have always considered .B time_t to be the wrong format for representing such historical data. .PP There are two possible solutions to the upcoming Y2038 crisis: .IP \(bu Change the 32-bit .B time_t type from signed to unsigned interpretation. Such a change would move the end-date from 2038 to some time in early A.D. 2106 (late SE144) at the expense of giving up the ability to represent proleptic dates in the 1901\(em1969 range. .IP \(bu Expand the storage allocated for each timestamp from 32 to 64 bits. .B 2**63 seconds equals hundreds of billions of years (using the current length of the Terran tropical year in SI seconds or in Terran MST seconds) and exceeds the current estimate for the age of the Universe by an order of magnitude, hence a 64-bit second count can be treated as either signed or unsigned as convenient, and can represent all known past and projected future. .PP Expanding .B time_t to 64 bits would be a more permanent solution (A.D. 2106 is a future date close enough to contemplate, hence an unsigned 32-bit solution has to be seen as a temporary band-aid fix), and to the best of this author's knowledge, it's the solution that has already been implemented by the more mainstream operating systems. However, shoehorning 64-bit .B time_t into an Ancient UNIX system such as 4.3BSD-Quasijarus would be .I extremely painful, and the much simpler unsigned 32-bit solution should be sufficient for the projected biological lifetime of the system's last remaining user. Therefore, the adopted Quasijarus solution is: .IP \(bu The current system is being patched up for unsigned 32-bit .BR time_t , officially redefining the meaning of 32-bit .B time_t values with the high bit set from the 1901\(em1969 range to the 2038\(em2106 range and extending the life of 32-bit-only systems till 2106. .IP \(bu If I live that long, I'll start working on a 64-bit-enabled version of Quasijarus some time in the 2nd half of the 21st century. .PP The changes for unsigned 32-bit .B time_t consist of: .IP \(bu The .B typedef for .B time_t in .B <sys/types.h> has been changed from .B long to .BR "unsigned long" . .IP \(bu The new Quasijarus versions of the .IR ctime (3) family of functions treat their .B time_t inputs as unsigned, producing dates between \%1969-12-31 (the epoch in time zones west of Greenwich) and \%2106-02-07. .IP \(bu The few places where the kernel does time comparisons for ordering will be fixed to make them correct for the unsigned interpretation. .IP \(bu Any other places in the code base that may be in need of fixing will be fixed as they are discovered. .PP Additionally, a new time data type has been created for safe processing and representation of data that may contain dates falling outside of the UNIX window of 1970\(em2106: see .IR mjdtime (3). .SH SEE ALSO date(1), gettimeofday(2), mjdtime(3), time(3) _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
