How to convert a TOD clock value to real time (by Paul Saers [email protected])

I do not guarantee that all the tables are 100% correct, but I hope they are!

Also note that dates are in ISO 8601 format (=international standard, not the way used in USA)

/Paul Saers (document location: http://paul.saers.com/TOD_howto)

The TOD clock is a 64 bit counter (bit 0-63) that started 1900-01-01 at the first microsecond of that new year. It started with all 0's. It has added one to bit 51 every microsecond since then. Fast machines add fractions of microseconds, as long as bit 51 is stepped once every microsecond - so what. This counter will wrap in the year of 2042. IBM has already expanded the TOD clock with more bits in front and also at the end (see later on this page).

How can we use the TOD value? How can we find out the value just now? How can we convert this value to more a meaningful to be used in normal life? Well - just read on.

After 100 years, the TOD clock was B361183F48000000 at the start of the new year 2000. Now, that is not exciting, since we already know the ansver. How about the value AAAAAAAAAAAAAAAA ? What date and time was that? Let us use that value and find out when this magical TOD clock value happened to be.

AAAA AAAA AAAA AAAA start value (spaces inserted for easy reading)
AA69 4A9B 9C00 0000 subtract start of 1995.001
0041 600F 0EAA AAAA remainder is less than a year
003E DD41 0C00 0000 subtract 50 days
0002 82CE 02AA AAAA remainder
0001 41DD 7600 0000 subtract 1 day
0001 40F0 8CAA AAAA remainder is less than a day. Our value was some time on 1995.052 (feb21)
0001 0C38 8D00 0000 subtract 20 hours
0000 34B7 FFAA AAAA remainder
0000 283B AEC0 0000 subtract 3 hours
0000 0C7C 50EA AAAA remainder is less than one hour. Our value was at 23.xx or late in the evening.
0000 0B2D 05E0 0000 subtract 50 minutes
0000 014F 4B0A AAAA remainder
0000 011E 1A30 0000 subtract 5 minutes
0000 0031 30DA AAAA remainder is less than one minute. Our value was at 23.55 only a few minutes before midnight.
0000 002F AF08 0000 subtract 50 seconds
0000 0001 81D2 AAAA remainder
0000 0000 F424 0000 subtract 1 second
0000 0000 8DAE AAAA remainder is less than one second
You could have arrived to this day by using the shortcuts in the bottom of this web-page

Our value was 1995 feb 21 at 23 hours 55 minutes 51 seconds, but didn't we have a remainder??. Yes, lets now use our hex calculator. We skip the last 12 bits (normally,some of these bits are used by MVS to tell what processor was used to read the TOD clock and what LPAR was active). This gives us a value of 8DAEA and we use the hexadecimal calculator to convert this to decimal. Yes, we get the value 580330. This is the number of microseconds in decimal that equal 8DAEA in hex.
So, a TOD clock value of all 'A's happened at 1995-02-21 23.55.51,580330

Is that the end of the story? Oh no. We can complicate it a little bit more. First of all, a good system runs with UTC (GMT was replaced with UTC years ago! but IBM still uses GMT) and not with local time. This is essential for networks crossing time zones and for 24/7 operations. By doing so, the need to stop the system when changing to or from daylight savings time is eliminated. The time we calculated is before midnight UTC, but after midnight local time in Sydney/Australia. Note that this happened in february, when it is winter (on the northern hemissphere) but Sydney has summer at this time and they do have daylight savings time as well. So, instead of the normal 10 hours difference, it is now 11 hours ahead.
In Sydney, the time was 1995-02-22 10.55.51,580330 (UTC+11)
In Dallas, the time was 1995-02-21 16.55.51,580330 (UTC-7)
Another value: what day will the TOD clock wrap around (well, what day will it need the extra byte in front)? Easy, just check the tables below and you find this to happen on 2042-09-17, but that is in UTC. Actually, this will be on sep 18 in London, since UK will (most likely) have daylight savings time and the event is after 2300 in the evening.

ISO 8601 article: http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Time zone's: http://www.timezoneconverter.com/cgi-bin/tzc.tzc


Below are links to full listings of TOD clock values for the beginning of the days. If you have the TOD clock value, find the relevant day by selecting the first character.

For TOD values starting with 0 click here--> 0.. 1900-01-01...1908-12-03

For TOD values starting with 1 click here--> 1.. 1908-12-03...1917-11-04

For TOD values starting with 2 click here--> 2.. 1917-11-04...1926-10-06

For TOD values starting with 3 click here--> 3.. 1926-10-06...1935-09-07

For TOD values starting with 4 click here--> 4.. 1935-09-07...1944-08-08

For TOD values starting with 5 click here--> 5.. 1944-08-08...1953-07-09

For TOD values starting with 6 click here--> 6.. 1953-07-09...1962-06-10

For TOD values starting with 7 click here--> 7.. 1962-06-10...1971-05-12

For TOD values starting with 8 click here--> 8.. 1971-05-12...1980-04-12

For TOD values starting with 9 click here--> 9.. 1980-04-12...1989-03-14

For TOD values starting with A click here--> A.. 1989-03-14...1998-02-12

Starting from here, I do include leap seconds as well. Leap seconds were added by IERS in Paris to allow for the difference between UTC and TAI. They had been added since a number of years and IBM included them before Y2K into MVS. But.... IBM did include 10 second too few. This has now been documented in the book: z/Architecture principles of operation SA22-7832-02 page 4-39 (and also in later versions). From here until present time, there are 3 tables. From left to right they are: The original TOD value, the TOD value according to IBM and missing 10 leap seconds ( this is the way MVS and its subsystems use the TOD clock ), the TOD value as it should have been if IBM had not dropped 10 leap seconds.
I do intend to update these listings as soon as I get the mail from IERS for the next half years status of number of leap seconds. So far, the listings are updated until 20231231.

For TOD values starting with B click here--> B.. 1998-02-12...2007-01-14

For TOD values starting with C click here--> C.. 2007-01-14...2015-12-16

For TOD values starting with D click here--> D.. 2015-12-16...2024-11-16

For TOD values starting with E click here--> E.. 2024-11-16...2033-10-18

For TOD values starting with F click here--> F.. 2033-10-18...2042-09-17

For TOD values for 0-1440 minutes, click --> min 0...1440 minutes

For fractions of a minute and other useful TOD values click here--> xx



About ISO8601 . . There seem to be a future problem built into the ISO8601 standard. As far as I understand, the date should be written as YYYYMMDD and that brings a problem after 99991231 when we(?) will start using 5 digit years. I leave this to be taken care of by future generations.
The TOD clock has been enhanced some time ago. Some people at IBM and also some other people in the industry do want to plan ahead. The year2000 ( Y2K ) is still in fresh memory. What will happen after 20420917 when the TODclock wraps around? Well... IBM has already enhanced the TOD clock. They added another byte in front ( and 3 more in the back, see apar OW38015 of 1999 ). This new front byte will stay 00 until 20420917 and then it will be 01 after the wrap has occured. Yes, it will be 02 some time in 2183 and keep growing. But, when will this new huge TOD clock wrap around? How long can we have this enhanced TOD clock? Well, it took me some time to calculate this and I must say that it is well ahead into the future. We (?) will have to wait until 384340817 ( the year 38434 aug 17 ) at UTC 21.43.32,153344 so that is aug 18 in Japan.
The above calculations do not take leap seconds inte account. Leap seconds are the difference between UTC and TAI. Today ( until 2024-12-31 ) they count plus 37 seconds. At that midnight, there might be one more inserted (or deleted). New leap seconds are announced by IERS in Paris a few months before they take effect and cannot be calculated by them so many months in advance. The IERS can announce both positive and negative leap seconds and there may be more than one to be inserted or taken away. Leap second adjustments can be done end of march, june, september and december, but have so far only been done end of june and december.


Is this of any help to you? Please tell me. Please link to these pages (and tell me). Please send comments and suggestions to paul @ saers. com

I have received help from Jozef Saers who coded the C-program to generate my first hex tables. Later updates have been done with the help of the mainframe assembler.