Back to Home PageXDAY! eXchange DAY! A Proposal by Bob Bemer Use the simple XDay method to avoid Year 2000 problems with interchange of date data. Yes, one standard has a four-digit year value as one part -- but
What follows is a selection and distillation of existing methods to propose a best way to interchange date data for our time and its emergency.
- The world doesn't have the time to change to conform.
- XDay is a nonconflicting, simple alternative that the world has ample time to use, and it is totally compatible with the four-digit form.
- four-digit years are people forms, cultural forms. Computers often use floating point calculation internally, but people don't. Computers often use binary arithmetic internally, but people don't.
XDay is an inside-the-computer, people-don't-see-it, form of date that is always simpler for computers to use.
- The method conflicts with no proprietary interests or prejudices, and works for all the world, not just for those using the Gregorian calendar. Nobody owns it! No religion, no government, no business type, no language group, no ethnic group, no continent has prestige or precedent to protect!
- XDay doesn't enlarge or change record formats or database pointers. It can intermingle with, and never be mistaken for, whatever current date form one uses. In short, it is self-identifying.
- Most people, for pennies, would be happy to see the external aspects of the total Y2K problem go away.
- Even the name "XDay" has never been used for this.
There is no need to give credits for sources; all are in the public domain, as this variation is. They exist from Joseph Scaliger on down, and may be found, if desired, by a search of the Web for "Julian Day" or just "Julian".
These appendices follow the main exposition:
THE XDAY RATIONALE
- TimeLine for XDays.
- Conversion between XDay and calendar, ordinal, and fiscal dates.
- Rebuttal arguments for any doubters and diehards that may remain after reading the main paper.
- How to discuss or argue with Bob Bemer.
- XDay calendar until Year 2000.
- Other Web References.
The Year 2000 problem has two distinct parts -- internal (fixing computer programs to work correctly for multiple centuries in one's own system), and external (exchange of date data with other systems). Any belief that both parts are equally difficult is wrong.
A single value can have many representations. The value six can be represented by "six" or "6" or "VI". A Reuters story of 1998 Apr 15 quoted Merrill Lynch as saying it would "cut off firms that are not prepared to deal with the Year 2000 problem." Contamination is feared. This doesn't make a four-digit year requirement, although odds are they won't accept "MMIV" for the year 2004. So representation is critical.
Interchange demands speaking the same language with the same symbols. As the world runs on networks of computers that vastly interconnect our lives, correct interchange of date data is critical to survival of that way of life.
The situation is akin to that in 1960 when computers had more than 60 different ways to represent their character sets. We fixed that with ASCII, but it took over four years to get it adopted as a standard, and not until PCs became prevalent was it really in force. Time is shorter now!
An air traffic controller in Brazil, having just asked, in Portuguese, a friend to get her a cup of coffee, speaks in English to the airplane pilot, who may be German. That's done worldwide for safety, and we need to use a similar interchange method worldwide for another form of safety in this Year 2000 crisis.
XDay is an easy method for universal date value exchange, but before explaining it let's look at the current situation.
THE PRESENT CONFUSION
Missing century is just a part of the problem. A date value for import or export may be expressed as YYMMDD or MMDDYY or DDMMYY. If it has four-digit years, use YYYY, not YY. If delimiters are used, it might show as DD/MM/YY. If in decimal numbers, each number might be in an eight-bit byte or in a four-bit compacted form. If bytes, it might be encoded in either ASCII or EBCDIC. If in binary numbers, DD and MM and YY might each be separate binary numbers, or they might be adjoined in a single binary number. Some programs use the ordinal (or nth) day of a year instead of month and day, as YYOOO. So a date might need anywhere from three to 10 or more computer characters.
Some existing methods don't even use decimal or binary numbers. Other methods give time in seconds or days, like internal clocks in PCs, UNIX, mainframes and the Global Positioning Satellites. If time is marked in seconds or days from some reference (starting) date, there is no standard reference starting time that everyone uses!
Thus there are NO standards for representing dates! Using four digits for years is recommended, naturally, but other than that - zilch! Very late in the day not to have standards for our interconnected world.
So the big question is -- with all these possible and existing usages, how do we KNOW WHICH? More properly, how does a stranger know? We know, of course, because it's implicit in the programs we are using. But that is not good enough. The XDay method solves all, in this way:
WHAT IS XDAY?
Only one unfailing human method of demarking time exists. Our EARTH rotates ONCE EACH DAY. Has and will. Two more rotations make it two days later. The only sure way to know the date is by how many days it is after some other day. Unsurprisingly a method exists. It's the JULIAN DAY system. Julian Day for the first day of Year 1 A.D. was 1721475. (Note: Some people use "Julian Day" erroneously to mean the Nth day of the year, rather than the Nth day of the Julian range).
For day 1 of the following centuries the Julian Day (in parentheses) is: 1800 (2378497), 1900 (2415021), 2000 (2451545), 2100 (2488070) ... 2400 (2597642).
The first digit stays the same for 27 centuries, and it won't roll over from "2" to "3" for 15 more centuries. So we DON'T NEED the leading "2"! Imply it, and call the 6 remaining digits
"XDay" (eXchange Day).May 16 of 1998 had XDay value of 450950. January 1st of 2000 (the most feared) is XDay 451545 (see the following display, augmented).
YYYYMMDD XDAY LILIAN YYMMDD MMDDYY DDMMYY 07630918 000000 07630919 000001 11090803 130000 15821014 299160 000000 15821015 299161 000001 16390104 320000 020840 18581116 400000 100840 581116 111558 151158 19000101 415021 115861 000101 010100 010100 19431003 431001 131841 431003 100343 031043 19990101 451180 152020 990101 010199 010199 19991231 451544 153284 991231 123199 311299 20000101 451545 152385 000101 010100 010100 20230224 460000 160840 230224 022423 240223 20380118 465440 166280 380118 011838 180138 (UNIX clock fails) 21320831 500000 200840 320931 083132 310832 24060616 600000 300840 060616 061606 160606 35010814 999999 700839 010814 081401 140801 35010815 >000000 700840 010815 081501 150801 YYYYMMDD XDAY LILIAN YYMMDD MMDDYY DDMMYY Lilian Day 0 was 1582 Oct 14, when Pope Gregory dropped 10 days for adjustments. This is as far back as the Gregorian Calendar can compute time properly without recourse to logic. But it has not the XDay property of being absolutely/uniquely identifiable as such. Any calculations with XDay prior to then can still be accomplished with program logic, maintaining that uniqueness of identification.XDay has some wonderful properties, the best being that, unlike the Lilian Day that IBM provides formulas for, it can't be mistaken for any other form of date. It's unique! (XDay = LilianDay + 299160)See the TimeLine in Appendix A. By Common Era Year 1102 XDay began with "13," so it can't be a month-day-year format, as months go only to 12.
By 1616 XDay began with "32", so it can't be mistaken for a day-month-year format, as days go only to 31.
XDay might have been mistaken for a year-month-day format in 1943, when calendar 43-10-03 equaled XDay 431001. But the YMD format is not a cultural format; it came into being primarily for computers, probably not until at least 1960. But assuming that it did show up in 1953, we have until October of 2214 (XDay=530000) before that conflict can occur! But by then we'll be totally converted, won't we?
This says you don't have to convert everything abruptly. Old formats and XDay can coexist intermixed during the transition. And XDay use does not require you to modify your other software or internal data.
But you may not derive XDays from two-digit years. If fed mistakenly to the conversion formulas, you'll get XDays with minus values. Obvious enough? You've found one!
A bonus is that the leading "2" of Julian Day, which XDay ignores, won't change to "3" until August of 3501. But warn your descendants they'll have a problem similar to what we had in 2000 if they don't cater to it. Although a shift of 26 centuries would be less confusing than just one.
The next best property is that XDay takes up exactly the same space in the data that any of our old forms did when they handled two-digit years. Users don't need to expand record and database formats; just fill them differently. The six digits of XDay handle 27 centuries, not just one.
Another fine property is that when one goes back to really fix the Year 2000 problem, Xday can be the main unit for all calculation. It handles leap years without a hitch (they're built in), provides elapsed days over many years (not just one, like Nth day does), and converts with ease in both directions to every other form of date - calendar, fiscal, ordinal, and non-Gregorian calendars like Imperial Japanese.
A still further advantage is that contrary to the internal difficulties everyone experiences in finding dates in the internal programs and data, people can usually pinpoint exactly the format and character of dates they input and output externally. See the copy books.
Consider the data transfer pipeline. A sender putting data into it first transforms the known date values, by trivial formulas in the public domain (See Appendix B), to XDay values. The receiver's transformer converts Xday values to the form they use, which may be different from the sender's. Does this differ in any way from the air traffic control language example?
As all date values go through this filter, anyone may use whatever form they wish to locally, probably just the form they've always been using.
We'd still use cultural forms for dates, but only for input and output from and to humans. All interchange between computers would be done in this standard XDay unit that they would all understand. Later, the internal calculations and storage could use XDays, too, in a gradual and very manageable changeover.
Can anyone think of an easier sort key than XDay?
XDay avoids the silly mistakes of PCs, UNIX, CPU clocks, and Global Positioning Satellites, et al, of using too short a time cycle.
XDay complies with U.S. Government GSA Federal Acquisition Regulation for Year 2000 compliancy, which verbiage permits XDays. It does not say you must provide four actual digits of the Gregorian Year. Only that:
"Year 2000 compliant, as used in this part, means, with respect to information technology, that the information technology accurately processes date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations, to the extent that other information technology, used in combination with the information technology being acquired, properly exchanges date/time data with it."The final advantage is that, like ASCII when it was developed, XDay is subject to no ownership or vested interest. No government, no religion, no language group, no ethnic group, no business, no political party, no continent has prestige or precedent to protect! As it coexists with all the world's existing calendars, all objections to its adoption can be overcome.
WHAT WE SHOULD DO
XDay can be made the gold standard, the lingua franca -- our salvation in the world of date interchange. Whatever you use at home, use XDay exclusively to represent the date in the world market. Providing (!) we get worldwide agreement to the following rule, even via laws:
In data interchange under private agreement between exporter and importer, both may represent date values in any agreed form.Absent such agreement, electronic interchange of date values must be done only in XDay form.
Will XDay solve the Year 2000 problem? Definitely not. Will XDay take the sting out of a possible collapse? Definitely yes. Will XDay serve to prevent the feared contamination in interchange? Yes, indeed. Can everyone convert in time? With the right authority, a good chance.
Will Xday cause added programming we can't afford? No way. A Microsoft programmer and checker could do it in a day for most of the PCs in the world! The code may even exist as a step to the "date" function from the binary clock that counts seconds (or near seconds) from start time. Know and store the XDay when the clock started, divide the reading by 43,200 (seconds in a day) and add to the start time! A Java applet is just as simple. Here's the DOS form:
C:\>xday Current XDay is 450950 Enter new XDay:Could we wish that every computer in the world processed dates in XDay form? Yes. It's absolutely the simplest and the best way. One would hope that for the future, once the present 2000 crisis is passed, that they would all be so programmed. It's as critical a standard as ASCII.
APPENDIX A
A Timeline for XDays (Common Era)
763 Sep -- Now XDay has the value 000000. 1101 Sep -- Now XDay cannot be mistaken for a month-day-year value like 12-31-01 1615 Oct -- Now XDay cannot be mistaken for a day-month-year value like 31-12-15 1858 Nov -- The 6-digit XDay begins with "4" 1880 -- XDay still begins with "4", and hardly anyone born before this date still lives 1950 -- XDay still begins with "4", and the computer era has just started 2000 -- XDay still begins with "4" when the danger era starts 2131 Aug -- XDay finally begins with a "5", but mankind has had time to fix everything 2406 Jun -- XDay begins with a "6", and if mankind still has not fixed everything, so what? The program logic is trivial! 3501 Aug -- XDay goes to "000000" again, and similar difficulty could occur. Historians and genealogists should have kept that leading "2" somewhere!APPENDIX BX DAY CONVERSION FORMULAS (between XDay and calendar, ordinal, and fiscal dates)
Variables: (Use only integer arithmetic!)
XD = XDay value XD1 = XDay for Jan 01 Ti = intermediate variables LY = Leap Year (1 if true, else 0) YYYY = 4-digit year MM = 2-digit month DD = 2-digit day NNN = 3-digit ordinal day FFFF = 4-digit fiscal year (may not = YYYY) WW = 2-digit fiscal week (max 53) D = 1-digit fiscal day of the week FC = fiscal constantMy 1980 TEX program "DATE" used this conversion plan:
- Leap Year
LY=1-(YYYY-YYYY/4*4+3)/4 LY=LY+(YYYY-YYYY/100*100+99)/100 LY=LY-(YYYY-YYYY/400*400+399)/400 LY=YYYY/4000 if remainder:eq:0 LY=0 (optional)- Calendar Date to Ordinal Date
do (1) NNN=3055*(MM+2)/100+(MM+10)/13*(LY-2)-91+DD- Calendar Date to XDay
T1=(MM-14)/12 T2=DD-2032075+1461*(YYYY+4800+T1)/4 XD=T2+367*(MM-2-T1*12)/12-3*((YYYY+4900+T1)/100)/4- Calendar Date to XDay for Jan 01
XD1=1461*(YYYY+4799)/4-2031738-3*((YYYY+4899)/100)/4- Ordinal Date to XDay
do (4) XD=XD1+NNN-1- XDay to Calendar Date
T1=XD+2068569 T2=4*T1/146097 T1=T1-(146097*T2+3)/4 T3=4000*(T1+1)/1461001 T1=T1-1461*T3/4+31 T4=80*T1/2447 DD=T1-2447*T4/80 T1=T4/11 MM=T4+2-12*T1 YYYY=100*(T2-49)+T3+T1- Ordinal Date to Calendar Date
do (1) T=NNN+((305+NNN-LY)/365)*(2-LY) MM=((T+91)*100)/3055-2 DD=T+30-(MM*3056)/100- Fiscal Constant
do (4) T=(XD1+2)-(XD1+2)/7*7 (or rmdr (XD1+2)/7) FC=T+7-(T+3)/7*7- Fiscal Date to Ordinal Date
YYYY=FFFF do (8) NNN=7*WW+D-FC do (1) if NNN:gt:(365+LY) YYYY=YYYY+1 NNN=NNN-365-LY if NNN:lt:1 YYYY=YYYY-1 do (1) NNN=365+LY+NNNNote: Input of fictitious dates may yield unpredictable results!
- Ordinal Date to Fiscal Date
do (8) FFFF=YYYY WW=(NNN+FC-1)/7 D=remainder+1 do (1) if WW:eq:53 if (FC+LY):lt:10 FFFF=YYYY+1 WW=1 if WW:eq:0 YYYY=YYYY-1 FFFF=YYYY do (1) YYYY=YYYY+1 WW=53-(FC+1-LY)/6
- XDay to Ordinal Date
do (6) do (2)- XDay to Fiscal Date
do (B) do (A)- Calendar Date to Fiscal Date
do (2) do (A)- Fiscal Date to Calendar Date
do (9) do (7)- Fiscal Date to XDay
do (9) do (5)APPENDIX C
Rebuttal arguments for any doubters and diehards that may remain after reading the main paper.A person confronted by death, due to some bad personal habit, will often change that habit in order to survive. A different diet, stopping smoking, whatever. But the change will be made only when one is aware of a solution, and has the opportunity to change.
A world confronted by a form of death may change a habit, but again only if it becomes aware of a solution, and has the opportunity to change.
That form of death is perceived in the Year 2000 problem for computers. Part of the solution is XDay, and yes -- there is an opportunity to change. Moreover, it can be done in the short time left. Therefore we must look upon XDay as an opportunity!
Will the person say "No, I can't save myself. The way to do it is contrary to a government rule"? Rubbish! A way to ease such a conscience follows.
Standards, no matter how official, always seem to have recognized alternatives. Esperanto, of course, is the standard designed for universal language. Yet it is not widely used in the United States because existing English is so prevalent.
Wait, you may say! English is not the standard language of the United States. Even though some states have attempted to make it so, judicial rulings have appeared to strike down such laws. Possibly because of conflict with other laws that specifically require the use of non-English.
Apparently countries will consider alternative practices permissible when high-volume usage exists. As another example, the metric system is the legal and official measurement system of the United States since about the mid-1800s. Can anyone prove the total absence of the old English measurement system in the laws of the United States?
Both standards and recognized and registered alternatives can coexist. In the case of ASCII and the ISO Code, this was made possible by the registry process. No one expected the Russians to change from Cyrillic to Roman alphabet just for a standard!
And there can be both standards and de facto practices. Most Brazilians speak Portuguese. But they will use English, as pointed out in the air traffic controller example. This may not be spelled out in Brazilian law, but it exists, and with excellent reason.
FOUR-DIGIT YEARS vs. DATES EXPRESSED IN DAYS
Some standards prescribe use of all four digits to express year values. In their original embodiment the titles said "... writing dates in all-numeric form". "Writing ..." We know no legally-enforced U.S. standards for expressing dates, especially not via year-month-day. To the contrary, a standard exists for expressing day values via only year and day. A U.S. Federal Information Processing Standard!
If it is permissible to have a special standard for Nth day of a year, why not for Nth day of a decade? Nth day of a century? Nth day of some arbitrary range of time? Like the Julian Day range?
Internal clocks for many computers measure time in a binary number of seconds within some arbitrary range. Would anyone dare to brand such a large group of the world's computers as non-standard? It would certainly be foolish to do so. And impossible to enforce. IBM would complain.
IBM would be right! After all, the standard time unit (the metric system, the SI tells us) is the second! Moreover the ISO Date Standard does not permit only four-digit years. Smaller options are mentioned specifically. See the NIST (US National Institute of Standards and Technology) ITL Bulletin for 1998 May.
These alternatives exist because there are exact transforms between representations. Rules that have existed for centuries, with rules for the Gregorian Calendar being about the most recent.
They exist because there are very good reasons, from an internal computer-use viewpoint, for them to exist.
They exist because they don't present the values visually to human users, who see only the transformed cultural values, of which there are many, even within the Gregorian Calendar.
Some who have been approached about the XDay method, like the Federal Reserve Board, insist that there must be only one way to interchange date values -- the eight-bit form. There are a few problems with that:
Thus XDay values live comfortably and without conflict in either eight- or six-character interchange.
- They think they don't need a recognizer program. But they do! How will they read ASCII date data when they think it is EBCDIC? How will they protect against bad interchange dates -- those with non-digits, with days and months outside limits, with century values out of current range, with eight-digit dates not in YYYYMMDD sequence? Where is the vaunted firewall?
- Once you have a recognizer for those, the recognizer can also detect if the first two digits of those eight are "00". If they are, it's an XDay value. If they are not, they had better be in the set "18, 19, 20".
- And of course an insistence on ONLY eight-digit fields means that many more users will never be able to convert on time.
- Not to mention the IRS (and perhaps some others) that still use some computers with six-bit bytes!
So to diehards anywhere: "Knock it off! We're trying to survive!"
APPENDIX D
How to discuss or argue XDay with Bob Bemer.
Contact him by e-mail at bob@bobbemer.com
voice: 940-779-4016 FAX: 940-779-2296Keep an open mind.
APPENDIX E
XDay calendar around Year 2000.
1999 M T W T F S S M T W T F S S ______________________________________________________________________ JAN 01 02 03 JUL 01 02 03 04 04 05 06 07 08 09 10 05 06 07 08 09 10 11 11 12 13 14 15 16 17 12 13 14 15 16 17 18 18 19 20 21 22 23 24 19 20 21 22 23 24 25 25 26 27 28 29 30 31 26 27 28 29 30 31 XDAY = 451179 + (day-of-month) XDAY = 451360 + (day-of-month) ______________________________________________________________________ FEB 01 02 03 04 05 06 07 AUG 01 08 09 10 11 12 13 14 02 03 04 05 06 07 08 15 16 17 18 19 20 21 09 10 11 12 13 14 15 22 23 24 25 26 27 28 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 XDAY = 451210 + (day-of-month) XDAY = 451391 + (day-of-month) ______________________________________________________________________ MAR 01 02 03 04 05 06 07 SEP 01 02 03 04 05 08 09 10 11 12 13 14 06 07 08 09 10 11 12 15 16 17 18 19 20 21 13 14 15 16 17 18 19 22 23 24 25 26 27 28 20 21 22 23 24 25 26 29 30 31 27 28 29 30 XDAY = 451238 + (day-of-month) XDAY = 451422 + (day-of-month) ______________________________________________________________________ APR 01 02 03 04 OCT 01 02 03 05 06 07 08 09 10 11 04 05 06 07 08 09 10 12 13 14 15 16 17 18 11 12 13 14 15 16 17 19 20 21 22 23 24 25 18 19 20 21 22 23 24 26 27 28 29 30 25 26 27 28 29 30 31 XDAY = 451269 + (day-of-month) XDAY = 451452 + (day-of-month) ______________________________________________________________________ MAY 01 02 NOV 01 02 03 04 05 06 07 03 04 05 06 07 08 09 08 09 10 11 12 13 14 10 11 12 13 14 15 16 15 16 17 18 19 20 21 17 18 19 20 21 22 23 22 23 24 25 26 27 28 24 25 26 27 28 29 30 29 30 31 XDAY = 451299 + (day-of-month) XDAY = 451483 + (day-of-month) ______________________________________________________________________ JUN 01 02 03 04 05 06 DEC 01 02 03 04 05 07 08 09 10 11 12 13 06 07 08 09 10 11 12 14 15 16 17 18 19 20 13 14 15 16 17 18 19 21 22 23 24 25 26 27 20 21 22 23 24 25 26 28 29 30 21 28 29 30 31 XDAY = 451330 + (day-of-month) XDAY = 451513 + (day-of-month) ______________________________________________________________________ 2000 M T W T F S S M T W T F S S ______________________________________________________________________ JAN 01 02 JUL 01 02 03 04 05 06 07 08 09 03 04 05 06 07 08 09 10 11 12 13 14 15 16 10 11 12 13 14 15 16 17 18 19 20 21 22 23 17 18 19 20 21 22 23 24 25 26 27 28 29 30 24 25 26 27 28 29 30 31 31 XDAY = 451544 + (day-of-month) XDAY = 451726 + (day-of-month) ______________________________________________________________________ FEB 01 02 03 04 05 06 AUG 01 02 03 04 05 06 07 08 09 10 11 12 13 07 08 09 10 11 12 13 14 15 16 17 18 19 20 14 15 16 17 18 19 20 21 22 23 24 25 26 27 21 22 23 24 25 26 27 28 29 28 29 30 31 XDAY = 451575 + (day-of-month) XDAY = 451757 + (day-of-month) ______________________________________________________________________ MAR 01 02 03 04 05 SEP 01 02 03 06 07 08 09 10 11 12 04 05 06 07 08 09 10 13 14 15 16 17 18 19 11 12 13 14 15 16 17 20 21 22 23 24 25 26 18 19 20 21 22 23 24 27 28 29 30 31 25 26 27 28 29 30 30 31 XDAY = 451604 + (day-of-month) XDAY = 451788 + (day-of-month) ______________________________________________________________________ APR 01 02 OCT 01 03 04 05 06 07 08 09 02 03 04 05 06 07 08 10 11 12 13 14 15 16 09 10 11 12 13 14 15 17 18 19 20 21 22 23 16 17 18 19 20 21 22 24 25 26 27 28 29 30 23 24 25 26 27 28 29 30 31 XDAY = 451635 + (day-of-month) XDAY = 451818 + (day-of-month) ______________________________________________________________________ MAY 01 02 03 04 05 06 07 NOV 01 02 03 04 05 08 09 10 11 12 13 14 06 07 08 09 10 11 12 15 16 17 18 19 20 21 13 14 15 16 17 18 19 22 23 24 25 26 27 28 20 21 22 23 24 25 26 29 30 31 27 28 29 30 27 28 29 30 XDAY = 451665 + (day-of-month) XDAY = 451849 + (day-of-month) ______________________________________________________________________ JUN 01 02 03 04 DEC 01 02 03 05 06 07 08 09 10 11 04 05 06 07 08 09 10 12 13 14 15 16 17 18 11 12 13 14 15 16 17 19 20 21 22 23 24 25 18 19 20 21 22 23 24 26 27 28 29 30 25 26 27 28 29 30 31 XDAY = 451696 + (day-of-month) XDAY = 451879 + (day-of-month) ______________________________________________________________________ 2001 M T W T F S S M T W T F S S ______________________________________________________________________ JAN 01 02 03 04 05 06 07 JUL 01 08 09 10 11 12 13 14 02 05 06 07 08 09 10 15 16 17 18 19 20 21 09 12 13 14 15 16 17 22 23 24 25 26 27 28 16 19 20 21 22 23 24 29 30 31 23 24 25 26 27 28 29 30 31 XDAY = 451910 + (day-of-month) XDAY = 452091 + (day-of-month) ______________________________________________________________________ FEB 01 02 03 04 AUG 01 02 03 04 05 05 06 07 08 09 10 11 06 07 08 09 10 11 12 12 13 14 15 16 17 18 13 14 15 16 17 18 19 19 20 21 22 23 24 25 20 21 22 23 24 25 26 26 27 28 27 28 29 30 31 XDAY = 451941 + (day-of-month) XDAY = 452122 + (day-of-month) ______________________________________________________________________ MAR 01 02 03 04 SEP 01 02 05 06 07 08 09 10 11 03 04 05 06 07 08 09 12 13 14 15 16 17 18 10 11 12 13 14 15 16 19 20 21 22 23 24 25 17 18 19 20 21 22 23 26 27 28 29 30 31 24 25 26 27 28 29 30 XDAY = 451969 + (day-of-month) XDAY = 452153 + (day-of-month) ______________________________________________________________________ APR 01 OCT 01 02 03 04 05 06 07 02 03 04 05 06 07 08 08 09 10 11 12 13 14 09 10 11 12 13 14 15 15 16 17 18 19 20 21 16 17 18 19 20 21 22 22 23 24 25 26 27 28 23 24 25 26 27 28 29 29 30 31 30 XDAY = 452000 + (day-of-month) XDAY = 452183 + (day-of-month) ______________________________________________________________________ MAY 01 02 03 04 05 06 NOV 01 02 03 04 07 08 09 10 11 12 13 05 06 07 08 09 10 11 14 15 16 17 18 19 20 12 13 14 15 16 17 18 21 22 23 24 25 26 27 19 20 21 22 23 24 25 28 29 30 31 26 27 28 29 30 XDAY = 452030 + (day-of-month) XDAY = 452214 + (day-of-month) ______________________________________________________________________ JUN 01 02 03 DEC 01 02 04 05 06 07 08 09 10 03 04 05 06 07 08 09 11 12 13 14 15 16 17 10 11 12 13 14 15 16 18 19 20 21 22 23 24 17 18 19 20 21 22 23 25 26 27 28 29 30 24 25 26 27 28 29 30 31 XDAY = 452061 + (day-of-month) XDAY = 452244 + (day-of-month) ______________________________________________________________________Summary of Day-of-month Additives1999 2000 2001 Jan 451179 451544 451910 Feb 1210 1575 1941 Mar 1238 1604 1969 Apr 1269 1635 2000 May 1299 1665 2030 Jun 1330 1696 2061 Jul 1360 1726 2091 Aug 1391 1757 2122 Sep 1422 1788 2153 Oct 1452 1818 2183 Nov 1483 1849 2214 Dec 451515 451879 452244APPENDIX F
Other Web References.
Note who has already prepared the way! IBM, NASA, etc. Not bad! Many of these are live convertors. Enter what you want converted.
1) cossc.gsfc.nasa.gov/cgi-bin/cossc/datecnv.pl 2) ednet.edc.gov.ab.ca/year2000/Microsoft%20Letter/AppendixF.html 3) qhs.com/clndar.htm 4) www-astro.physics.ox.ac.uk/~erik/sax/handy_tools.html 5) www.cdc2000.com/cd06000.htm 6) www.genealogy.org/~scottlee/calconvert.cgi 7) www.hep.net/wwwmirrors/cernlib/CNASDOC/shortwrups_html3/node273.html 8) www.software.ibm.com/year2000/tips15.htmlNote particularly the last link, where IBM provides actual code. The only difference from XDay calculations is that XDay = LilianDay + 299160.And don't miss "Today's Calendar and Clock Page" at http://www.panix.com/~wlinden/calendar.shtml
-- Bob Bemer, published November 1998