On time
Time is an interesting thing. One moment in time, the seconds it took you to read this sentence, can never be retrieved. According to modern science, those precious moments travel along a line. It starts at t = 0 and travels along in dt intervals until you've reached your conclusion. (The interval measurement, dt, is so infinitesimally small that it cannot truly be measured. Imagine 1/x as x approaches infinity, and you'll get the idea ... or your head will cave in.)
However, I'm not going to write about how time is measured for the purpose of high school and college physics experiments, or how time is fleeting, escaping us day by day, second by second, and that even after our sun has gone supernova and scorched this rock we call home to the point of total lifelessness, time will still unrelentingly tick on. No, I'm going to talk about how time is stored on machines. (I recently found myself in a position to convert a 64-bit date and time value from an VMS format to a 32-bit POSIX date and time format, so I'm feeling a bit chatty about this topic.)
In practice, converting one to the other is fairly simple. You start with your 64-bit date value. Subtract 35,067,168,000,000,000 from this. Then divide by 10,000. Simple, right? The reason for all of this is somewhat convoluted, but I want to try to explain it anyway.
If you want to measure the passage of time, you need to start with a base date. If you're a non-Christian who tries fervently to eschew Christian influence in modern society, you probably use midnight, January 1st of the year 1 of the Common Era. If you're a Christian or someone who lives in a Christian dominated society and just doesn't care about the "politically correct" yahoos out there, then you probably use midnight, January 1st of the year 1 Anno Domini. They are both the exact same point in time. If you are any other culture (such as Chinese, Japanese, Jewish, Mayan, etc.) then you may have a different base date altogether, and I'm too lazy to do the research to figure out what that is. As a result, we'll be sticking to the Gregorian Calendar. In computer lingo, these base dates are called "epochs."
The epoch used is dependent upon which Operating System or programming language you're using. DOS, for example, uses January 1st, 1980, while Windows uses January 1st, 1601. POSIX uses January 1st, 1970 (this is also the base year for many programming languages, including C/C++ and Java.) VMS uses November 17th, 1858.
Also, computers can't use an infinitesimally small dt to increment their time value. DOS, for example, used the abysmally inaccurate value of 2 seconds, while IBM's z/OS uses the extreme of 244.14 picoseconds (it's really small. Trust me.) Getting back to my VMS/POSIX example, I had to convert 64-bit VMS dates (which start on November 17th, 1858 with a dt of 100 nanoseconds) to 32-bit POSIX dates (which start on January 1st, 1970 with a dt of 1 millisecond). The algorithm, or logical list of steps, is to determine the difference between the epochs according to one dt unit of measurement and then convert to the other dt unit of measurement. It doesn't have to be in this order, but that's how I chose to do it.
Dates are tricky. You have to take into account the fact that each solar year (which is the time it takes for the Earth to orbit the Sun) is 365.25 days (which is the amount of time it take for the Earth to rotate on its axis and which means that every fourth year has that extra day in it). This means that every four solar years has 1,461 days, and every 100 solar years has 36,525 days. The total number of days between November 17th, 1858 and January 1st, 1970 are 40,587. This must then be multiplied by the number of 100 nanosecond ticks in a day, which is 864,000,000,000. The result is 35,067,168,000,000,000 100 nanosecond ticks between epochs. Since this is the difference in 100 nanosecond ticks between the two epochs, you can take any VMS date and subtract this value to get a 100 nanosecond offset from the new epoch of January 1st, 1970. Now all you have to do is convert nanoseconds to milliseconds. There are 1,000 milliseconds in a second, and 1,000,000,000 nanoseconds in a second. This means that the conversion is 1,000 / 1,000,000,000. However, since VMS adds 1 to its time counter every 100 nanoseconds, we multiply the conversion ratio by 100. This means that we divide whatever result we get from the subtraction by 10,000.
Just what you wanted to know!
Look at y = 1/x. When x = 2, y = 1/2. When x = 3, y = 1/3. When x = 10, y = 1/10. When x = 1,000, y = 1/1,000. y gets smaller as x gets larger. As x increases towards infinity (x can't be infinity, because infinity is not a number) y gets closer and closer to zero, but never actually becomes zero.
However, I'm not going to write about how time is measured for the purpose of high school and college physics experiments, or how time is fleeting, escaping us day by day, second by second, and that even after our sun has gone supernova and scorched this rock we call home to the point of total lifelessness, time will still unrelentingly tick on. No, I'm going to talk about how time is stored on machines. (I recently found myself in a position to convert a 64-bit date and time value from an VMS format to a 32-bit POSIX date and time format, so I'm feeling a bit chatty about this topic.)
In practice, converting one to the other is fairly simple. You start with your 64-bit date value. Subtract 35,067,168,000,000,000 from this. Then divide by 10,000. Simple, right? The reason for all of this is somewhat convoluted, but I want to try to explain it anyway.
If you want to measure the passage of time, you need to start with a base date. If you're a non-Christian who tries fervently to eschew Christian influence in modern society, you probably use midnight, January 1st of the year 1 of the Common Era. If you're a Christian or someone who lives in a Christian dominated society and just doesn't care about the "politically correct" yahoos out there, then you probably use midnight, January 1st of the year 1 Anno Domini. They are both the exact same point in time. If you are any other culture (such as Chinese, Japanese, Jewish, Mayan, etc.) then you may have a different base date altogether, and I'm too lazy to do the research to figure out what that is. As a result, we'll be sticking to the Gregorian Calendar. In computer lingo, these base dates are called "epochs."
The epoch used is dependent upon which Operating System or programming language you're using. DOS, for example, uses January 1st, 1980, while Windows uses January 1st, 1601. POSIX uses January 1st, 1970 (this is also the base year for many programming languages, including C/C++ and Java.) VMS uses November 17th, 1858.
Also, computers can't use an infinitesimally small dt to increment their time value. DOS, for example, used the abysmally inaccurate value of 2 seconds, while IBM's z/OS uses the extreme of 244.14 picoseconds (it's really small. Trust me.) Getting back to my VMS/POSIX example, I had to convert 64-bit VMS dates (which start on November 17th, 1858 with a dt of 100 nanoseconds) to 32-bit POSIX dates (which start on January 1st, 1970 with a dt of 1 millisecond). The algorithm, or logical list of steps, is to determine the difference between the epochs according to one dt unit of measurement and then convert to the other dt unit of measurement. It doesn't have to be in this order, but that's how I chose to do it.
Dates are tricky. You have to take into account the fact that each solar year (which is the time it takes for the Earth to orbit the Sun) is 365.25 days (which is the amount of time it take for the Earth to rotate on its axis and which means that every fourth year has that extra day in it). This means that every four solar years has 1,461 days, and every 100 solar years has 36,525 days. The total number of days between November 17th, 1858 and January 1st, 1970 are 40,587. This must then be multiplied by the number of 100 nanosecond ticks in a day, which is 864,000,000,000. The result is 35,067,168,000,000,000 100 nanosecond ticks between epochs. Since this is the difference in 100 nanosecond ticks between the two epochs, you can take any VMS date and subtract this value to get a 100 nanosecond offset from the new epoch of January 1st, 1970. Now all you have to do is convert nanoseconds to milliseconds. There are 1,000 milliseconds in a second, and 1,000,000,000 nanoseconds in a second. This means that the conversion is 1,000 / 1,000,000,000. However, since VMS adds 1 to its time counter every 100 nanoseconds, we multiply the conversion ratio by 100. This means that we divide whatever result we get from the subtraction by 10,000.
Just what you wanted to know!
Look at y = 1/x. When x = 2, y = 1/2. When x = 3, y = 1/3. When x = 10, y = 1/10. When x = 1,000, y = 1/1,000. y gets smaller as x gets larger. As x increases towards infinity (x can't be infinity, because infinity is not a number) y gets closer and closer to zero, but never actually becomes zero.
posted by Doug Murata at 7:59 AM
3 Comments:
Aaagh!
Thanks for trying to explain, Doug. I think I sort of get it. Maybe.
The over-riding concern for me is how much religion can cause problems for computers.
I can't help imagining that, if computers were in charge, they would just set the year to zero from the nanosecond they came into power; no sentimentality, just pure economical logic.
And this is exactly why I choose to look at time as a way of measuring events as opposed to the other way around - though I don't think what I just wrote makes sense anywhere other than in my head.
As for Windows using January 1st, 1601, I think this is just another way of them saying that they were around long before Apple - and that they created everything first. Revisionist history and nothing more, I tell you!
Ultra: Not just religion, but culture, as well. In Japan, for example, eras are broken up by the life of each Emperor. Once an Emperor dies, he is given a new name, and the period of his life is called by this new name. As a result, you don't know what to call the era in which you live until the Emperor is dead. This method of marking dates is currently in use on enterprise level computer systems and it boggles my mind that anyone would consider it a good idea to even attempt to create.
As far as computers are concerned, they could use the initial time of their reign as year 0. Just add or subtract to that as necessary. If you set the time resolution properly, you can measure time as far ahead or back as 30,000 years with 100 nanosecond precision, or 2 billion years with millisecond precision. Sometimes the removal of sentimentality just makes things easier!
Joe: Revisionist history, indeed! Especially considering that Bill Gates initially attempted to sell his product for use on the Apple, got ignored by Steve Jobs and, in something of a fit of revenge, went to IBM with a non-existant OS called DOS.
How did MicroSoft help to shape the development of the world with such humble beginnings in 1601, I wonder? Perhaps theirs was the word processor used to draft the Declaration of Independence, with a custom font for John Hancock's signature? After noticing the cramps from writing the Magna Carta, I'm sure typing such a document was much preferred.
Post a Comment
<< Home