| Unix Time | Gregorian Time(ET) | Greenwich Time (UTC) |
|---|---|---|
| 1000000000 | Sep 8, 2001 9:46:40 pm | Sep 9 1:46:40 am |
| 900000000 | July 9, 1998 12:00 noon | 4:00 pm |
| 800000000 | May 9, 1995 2:13:20 am | 6:13:20 am |
| 700000000 | Mar 7, 1992 3:26:40 pm | 8:26:40 pm |
| 600000000 | Jan 5, 1989 5:40:00 am | 10:40 am |
| 500000000 | Nov 4, 1985 7:53:20 pm | Nov 5 12:53:20 am |
| 400000000 | Sep 4, 1982 11:06:40 am | 3:06:40 pm |
| 300000000 | Jul 5, 1979 1:20:00 am | 5:20 am |
| 200000000 | May 3, 1976 3:33:20 pm | 7:33:20 pm |
| 100000000 | Mar 3, 1973 4:46:40 am | 9:46:40 am |
| 0 | Dec 31, 1969 8:00 pm | Jan 1, 1970, 12:00 mid |
It takes 3 years, 62 days, 9 hours, 46 minutes and 40 seconds for 100 Msec to pass.
Being that 900M occured at high noon ET, July 9, 1998, a period during which I was employed full time, I fully intended to mark the occasion with something notable. Alas, I missed it entirely and didn't even realize it until months later.
I definitely plan on doing something for 1B. I should probably start thinking about what, exactly.
If my chart is to be believed, I have lived through 8 such milestones, from 200M to 900M. On the internet, I have seen 800M and 900M. (In my early days on the Internet, seeing Unix dates was quite common, as they were visibly used as datestamps by IRC servers.) I estimate I started using the internet ca. 788M.
I like the idea of using Unix dates as a replacement for Gregorian years, for the same (or similar) reasons some use the Discordian calendar, the World Calendar (which I thought about using), Star Trek stardates, or even their own personal calendrical notations
Unix dates can be easily truncated, with SI modifiers to indicate the point of truncation, i.e. 900M, which could be used to refer to the general time period between Jul 9 and Jul 21, 1998 (12 days or 1Msec), or could refer to any time between 900M and 1B, from Jul 9, 1998 to Sep 8, 2001. This notation could be easily fractionalized, so that you could say 0.90B to refer to the period from 7-9-1998 (900M) to 11-2-1998 (910M).
Most of this is unnecessary, as you would normally be using this notation for immediate points in time (at this point in writing this, it is 948903845) or current dates (one could say today is 948900k, roughly, as there are 86400 sec in a day). For vague ranges of time, you could say "around 788M", using significant zeros ambiguously (e.g. "around 800M"), the same way we currently do when we say "the 1900s".
You would of course also need some symbol or mark to indicate that the number you are giving is a Unix date. (Technically, some might say, this is really a C date, not limited to Unix; but seeing as C and Unix were essentially made together, either seems appropriate.) I would prefer "U.d." as a symbol, or UD or something like that. You could then say something like "948 MU.d.".
It seems not at all unnatural, as a computer professional, that my personal date system should have some close relationship with computer time. Many admitted geeks, of course, have a certain penchant for the Illuminatus! stories, and they might be more drawn to the Discordian or Erisian calendars of that lore.
Hmm. What was the calendar system used on the Discworld?
-- Kdt, 948904398
Most of the side effects of the rollover had actually started causing problems in ca. 1998, when the first report of a Y2K-related problem hit the news: a case of a credit card holder having his credit refused because his newly issued card had expired 96 years earlier (in '02 -- that is, 1902). Needless to say, the barrier to commerce encouraged those affected applications to be fixed far in advance of the actual date rollover.
Beyond those early twinges, the systems which were really expected to experience major failures were not critical systems (e.g. power generation, life support, traffic control, etc.) themselves, but billing and reporting systems attached to those systems, and even in the byte-scrounging early days of microcomputer programming, a responsibly put-together computer system did not allow such auxilliary operations like billing (remember, most of these were made in the long-haired 60's) to cause disastrous failures in the performance of the critical tasks.
That having been said, with Unix remaining a common, and increasingly popular, platform for critical applications, especially data storage and serving, there does exist a 'bug' in all (AFAIK) versions and brands of Unix (including Linux, IIANM) which will cause major problems when a particular date is reached.
The UNIX date structure cannot recognize dates later than 10:14:07 PM (ET), January 18, 2038. Presumably, quite a number of things, if not the entire system, will fail under Unix when that date is reached.
The reason for this is manyfold. For one, UNIX (i.e., C) date values are stored in a space of 4 bytes, a total of 32 bits. This means that the total number of different values recognizable by such a value is 2^32, or slightly over 4.2 billion.
Theoretically this means the maximum value recognizable is 4.2 billion. The structure used, however, also expects negative values, so the maximum value is about 2.1 billion.
This value is a count of seconds, and when you take into account that one year (365.24 days) accumulates over 31 million seconds, 4.2 billion seconds holds just over 136 years. (This of course is 36 years better than 2 decimal digits.) Now, zero seconds is defined as midnight, January 1, 1970 Greenwich time. 2.1 billion seconds after that time will fall in mid January, 2038.
This will probably be solved before then, assuming that Unix is still widely used 38 years from now (and judging by the number of VAXes still in use in 1999, this isn't unlikely). The presumable fix would be to alter the C date structure such that it can recognize more different values, by making it bigger. The common fix in such a situation is to double the size of the field, which would mean over 18 quintillion different values, which would allow for 584 billion years. This would double the size of all files, memory, and other stored data containing date values (that is, the amount of space actually containing dates); but presumably, with the current (very late 20C) advances in disk drive technology, Moore's Law, and all that, data storage technology will be quite advanced enough in 2038 to handle such an increase.
My choice of measuring "unix time milestones" as being intervals of 100Msec was mainly driven by my discovery of 900M U.d. being smack at noon (ET) on the subsequent July 9. It was ca. 890M U.d. when I discovered this. Intrigued, I "calculated" (mainly by hit-and-miss with GNU date) the ET and GMT dates and times for each 100Msec interval, and for lack of a better name, called them "Unix Time Milestones."
Three years and two months seems a far enough apart span of time to have an excuse to celebrate something time-worthy, just like one might (MIGHT) do for blue moons, solar eclipses, etc. 10Msec is only a little under 3 months; way too short. 1Bsec is about 31.7 years, and now we're talking about the space of time people wait for major comets; way too far apart to be notable, and besides, as already pointed out, you can only have two of them before the date field craps out on you. No good.
This doesn't answer the question of why not use a more computer-related numeric interval to base the milestones of our computer-related time system on. The first alternative one might strike upon would be the near-decimal progression of byte-based data measurement where 1024 (2^10) units = 1K' units, 1024^2 (2^20) units = 1M' units, and so on.
Well, d1M' U.d. = ~ 12 days. d10M' U.d. = 121 days or 4 months, and d100M' U.d. = ~ 3 years, 4 months. To be honest, it's not far off from 100Msec. You do not even get the benefit of having an even number of them, since 2^20*100 is not evenly divisible into 2^30.
(I don't have the time to calculate all these; maybe later.)
Then what about straight binary, wherein you will have an even number of them, and wherein the final Milestone will come to a cataclysmic concidence with the End of the World (Unix).
You could divide the 2.1B U.d. space into 8 nice byte-sized pieces, each of which would measure just over 8.5 years. Too long. The next resonable division, if you follow the binary idea, would be into 16 pieces, being 4.25 years long. Or 32 pieces, each 2.13 years long.
Well, IMO, 2 years and 1.5 months is too short and too close to just being semiannual. 4 years and 3 months is better. Regardless, I personally like 3 years and 2 months better, possibly because you don't have to wait as long for them, and because you will have more of them.
So far we are about 40% through life as Unix knows it. The midway point comes at 1/10/2004 8:37:04 AM EST.
There will be a total of 21 100Msec milestones; 10 will happen before the midpoint and 11 after. The last will be 2100Msec, at 7/18/2036 8:20:00 AM EST; nearly 1 year and 6 months before the end.
For mostly human chronological reasons, and in respect to the Gregorian calendar which we still must all use, the 100Msec / 3.16 year interval is most attractive, especially if we think of UTM's as being an exclusive, significant event that only those using U.d. would celebrate.
The Binary Year
If one could live in an ideal world where one would only ever have to use
U.d., you could perhaps divide 2 B' sec into 64 parts, each being 388.36
days long, or 1 year, 23 days (..., 8 hours, 38 minutes, 24 seconds).
This isn't bad; we could call it a 'binary year.' The only problem is that
after only 8 years, these points will be half a year off from the solar
year. As an earthbound measurement of time (by which one lives one's daily
life), it would not appear to be very convenient. But perhaps it is still
worth observing.
Binary Year Dates
A calendar based around such a year, in order to be used on Earth by
solar day-based humans, would need to somehow become onto the set of
days. I tried to accomplish this with some not-too-involved math.
The first step was to decide on a subinterval. All good yearish periods need a monthish subinterval. Since these monthish intervals need monthish designations, I chose 16 subdivisions, which would each be numbered from 1,2,3, through to ,E,F,10. (One might also give them geekish names like Atto, Femto, Pico, etc.) Most months have 24 days; but this would give 384 days. We need to come to 388 days, so every fourth month is 25 days.
Now we're stuck with the .36 day left over. This means we need an extra (i.e. 'leap') day every 2.77 years. We come close to this by adding a day every third year. But this isn't enough, and by the 14th year we need to make the leap already. So this means we have a 14 year cycle, over which the 3rd, 6th, 9th, 12th, and 14th years need a leap day.
This still will be off, eventually. I've estimated that after 14 of these cycles, we will need to correct again, by adding yet another day. And still, an error will remain. I'm not going to worry about that personally, because that will be 166 years from now, and the remaining error will take 558 years to surface. (And that's in Binary Years.)
So the months will be: Atto, Femto, Pico, Nano, Micro, Milli, Centi, Deci, Deka, Hecto, Kilo, Mega, Giga, Tera, Peta, Exa. Nano, Deci, Mega, and Exa are 25 days while the rest are 24. The leap day will occur on the 64th day of the year (close to the Gregorian leap day, which is on the 60th day of the year), on the 16th day of Pico. (Pico will be 25 days long in such a year.)
Now the trick is converting Gregorian date to Binary Year date. This is really best done by calculating the days since the Epoch (0 U.d.), and then calculating up. GNU date will tell me midnight starting today (Mar 6 2000) is 952300860. Divide by 86400 (seconds in a day) and that's 11022 days. Divide that by 388.36 days and get 28.3808; that means 29 is the current Binary Year.
We know that one 14-year cycle is 388 * 14 plus 5 extra days = 5437. Divide 11022 by 5437 and get 2.0272; we are in the 3rd cycle. Subtract 2 cycles from 11022 and get 148 days. So we are in year 1 of the 3rd cycle, aka year 29 (well, we already knew that) -- normally we would have to subtract the time taken by the years so far in this cycle, including leap years. In order to find the date, we need to move through the months; every month is an average of 24.25 days, so 148 / 24.25 = 6.1030, which makes it Centi. .1030 * 24.25 = 2.5, so it is the third day of the month.
So the Binary Year date is Centi 3, 29 UE (Unix Era).
Should we name the 14-year cycles to give them prominence? What would you call them? I might be inclined to define 14 year periods according to something significant about the period. Like Terminal Cycle (1970-1985), Modem Cycle (1985-2000), Broadband Cycle (2000-present). Or after people, though I don't know many people who can be identified with a 15-year period, nor do I know of an appropriate geekish personality covering 1970-1985. The Thompson Cycle? Let's forget about this.
--Kdt, 952320356