Global Date Time for E-Business Concept, rationale and implementation.

Henry Keultjes, MD-Linux Scientific, Mansfield Ohio USA

v1.0, 18 July 2001

This document provides information about Global Date Time for E-Business Concept, rationale and implementation. GDT is a globally uniform method for computers and computer software to relate date and time elements to other computers and application software.

1. Global Date Time for E-Business Concept, rationale and implementation.

GDT is a globally uniform method for computers and computer software to relate date and time elements to other computers and application software.

The purpose of GDT is to simplify the initiating and completing of e-Business contracts all over the world using improved date and time handling based on existing standards.

Business contracts are always specific as to date(s). When more precision is required, contracts also specify time as to date(s) because business contracts, by their nature, do not make assumptions as to a date. Thus, in business contracts, time and date are inseparable.

Time not only depends on the day, it also depends on the time zone where the 24-hour clock starts. Therefore business contracts also require that a time zone like EST or EDT be specified.

As more and more business is contracted with partners all over the globe, the use of local time in business contracts becomes increasingly complex and specifying all business contracts as to a global date/time line becomes a necessity.

Obvious choices for a global date/time line are the International Date Line (IDL) and the zero meridian which intersects Greenwich England and which time line is popularly known as Greenwich Mean Time (GMT). GMT has long been used to coordinate sea and air navigation and to a lesser extent (in the past at least), global business transactions. Of the two choices, precedent favors the zero meridian for coordinating global business transactions.

A more compelling reason than precedent for using the zero meridian as the global date/time line is that Coordinated Universal Time (UTC) is determined at the zero meridian. UTC is now the preferred term for specifying time at the zero meridian. UTC is determined by a series of atomic clocks which are, by adding or subtracting a leap second at a time, periodically synchronized with our natural time, the rotation of the earth.

UTC is supported by an existing global infrastructure of radio stations, network signals and dial-up services and software capable of synchronizing (computer) clocks to within a fraction of a second.

Sophisticated business computer systems, and the (telephone) network over which these systems operate, have long used UTC as the time standard to which they synchronize so that they can initiate and complete global transactions without confusion about time.

Traditionally, these sophisticated computer facilities were staffed around-the-clock by computer professionals who understood UTC because they "lived" on UTC, but these people were still anchored to their local date.

As more and more companies participate in global trade, the responsibility for e-Business transactions has shifted more and more away from these computer professionals, living on UTC, to transaction-oriented employees.

Unlike computer professionals, transaction-oriented people think in terms of local time because their responsibilities typically center around initiating and completing e-Business transactions relative to local demand. However, in their responsibility for global e-Business transaction, their work is more complex than that of the computer professionals because they not only have to think in terms of both UTC and local time, they also have to think in terms of two dates because UTC, always spans two dates except at 12:00 (on a 24:00 clock).

GDT solves this dual date/time dilemma. It provides for the computer to computer transaction to be conducted using a new system, a universal global date/time in a format best suited for the computer, while the people who execute the transaction use the same old local cultural date/time format that suits them just fine. This is clarified by a simple example:

Joe, an employee of AMD in California, enters an order for 4000 Athlon chips with their Dresden Germany fab at 10:00 AM on 05/01/2000. The California computer translates the transaction date and time into 51664:64800 and transmits that to Dresden in that same 51664:64800 format. When Hans, the German production control foreman, looks at his screen he sees that California ordered those 4000 Athlon chips at 18:00 on 01 Mai 2000. His computer translated the transaction into his typical German format. Neither Joe nor Hans had to be concerned about dealing with each other's date and time format idiosyncrasies because the universal system in the middle provided the translations, effortless except for the one time effort of a brilliant programmer.

GDT uses the UTC derived Modified Julian Date (MJD) as the ordinal internal computer date, which date is internally subdivided into seconds. That internal date/time format JJJJJ+SSSSS for 20 seconds after midnight on 01 January 2000 will be 51544:00020.

On a normal date, the seconds increment through 86439 while at the end of the next second the ordinal date increments by one to 51545 and at that point date/time becomes 51545:00000.

On leap second days, the computer either increments the day one second sooner or one second later, depending on whether a second has to be added or subtracted to bring UTC back into synchronization with the rotation of the Earth.

Since a computer's Real Time Clock (RTC) runs on this internal format while all e-Business is transacted in terms of that same internal date/time format, both the so called firmware and the Operating System (OS) software translate the internal date/time format into local date/time presentation that the computer user sees, typically in the corner of the screen. That same local date/time presentation is also used for screen and printer output in typical applications.

Examples of such date time presentations are:

51544:36000   5:00 AM EDT January 1, 2000
51544:36000  10:00 01 January 2000 - London
51544:36000  01:00 02 January 2000 - Sydney Australia
51544:36000   4:00 AM 01JAN2000 Custom Format - Chicago
Chinese ??

All e-Business protocols can use these standardized interchange format JJJJJ:SSSSS for date/time so that these various initiatives can concentrate on objectives of their specific standard knowing that the common date/time standard for all e-Business initiatives is there to use.

2. Comments to GlobalDateTime for e-Business

Greenwich Electronic Time was established at Greenwich, England at the end of 1999. With that action, the GET-Time organization - see - validated the need for a global e-Business time standard. With that same action, GET-Time also validated my four year effort to establish as a standard a Pick like internal ordinal date methodology for exchanging date/time elements in e-Business. That initiative was named GlobalDateTime (GDT) in June 1999 to reflect that, for e-Business purposes, time and date are inseparable.

It is interesting that, since December 1999, when my efforts to spread the word about GDT have included references to GET, I have received a lot of negative comments about the involvement of UK Prime Minister Tony Blair in the GET initiative. One might expect that, as a businessman, I would likewise look negatively upon Mr. Blair's involvement but that is not the case. Quite to the contrary! Let me explain that stance with an analogy as to why Y2K happened and thus explain why it is important to also have government leaders involved in efforts like GDT and GET.

Human nature, it seems, expects government to come riding in on a white horse when crises, national in scope like war and Y2K, pop up. These are crises that have little chance for resolution if acted upon only by one person or a few persons. Instead such issues require a much wider, coordinated involvement of those affected in both business and government in resolving the crisis. The ability to resolve issues like Y2K, GDT and GET therefore gains momentum only if a whole nation, a whole group of users or a whole group of nations can be persuaded to get involved in solving the issue. That's why I believe that it is good to have Prime Minister Blair involved in GET.

The computer date rollover problem, not called Y2K then, was known at least since 1965 when a group of engineers at TRW substituted the then 5-digit date format 50101 (yes that was before the 2 digit year) on the IBM 360 with an ordinal date format, the Pick Internal Date, supposedly to meet the perpetual term in a contract for a system to inventory U.S. Army helicopter parts. In February 1981 an article by Joe Celko about the looming Y2K problem appeared in one of the most widely circulated professional computer periodicals of that time, Information Systems News. Thus by mid-1981 the Y2K problem should have been known to every self-respecting MIS manager who had made an effort to read at least some industry relevant publications. Yet, nothing much was done to avert the impending disaster.

What if, in mid-1981, someone had been able to convince President Reagan to get involved in the Y2K issue? Had asked him to invoke a deadline, say eight years hence, on all US Government installations and those in any way connected to it, (which means every company in the US that pays wages) for making the necessary changes? The Y2K situation would have been taken care of with ten years to spare and there would never have been a Y2K crisis at a cost of $600 billion - not my figure. The fact that President Clinton had to step in and establish a $50 million crisis center proves my point that certain issues, issues that industry should be quite capable of resolving on its own, nevertheless do not get resolved and thus such situations require government involvement and coordination.

I have also received quite a few comments asserting that the need for a global date/time standard is already filled by UTC (Coordinated Universal Time) popularly known as atomic time. Because of the Y2K situation, I see a real need to approach the global date/time issue from a rational standpoint, without getting hung up on the technical details, as technical people are bound to do. Instead, I am approaching this issue from a business standpoint. In order to function smoothly, business applications need a global standard for storing date/time elements in applications, a standard that also provides for the ability to exchange those same standard elements between applications. UTC does not do that nor does UTC interfere with GDT.

While I am a businessman, not a programmer, I can read through some Basic code. I am also an interface and systems designer who designed our own (now called) Demand Flow ERP/CRM system in 1978. I therefore have more than superficial knowledge of computer systems and software and I have a knack for looking for ways to improve something, rather than taking the attitude that "If it ain't broke, don't fix it". From that perspective I am concerned about the fact that, like in the Y2K situation, very few people are willing to admit that the lack of a globally uniform method of communicating internal date/time elements between computers and application software is a problem. I, on the other hand, believe that, the longer we go without agreeing on such a global standard for an internal computer date/time, the more code will have to be changed eventually and that need to change all that code will then, once again, turn into a very expensive project, just like Y2K.

Most technical people also disagree with me on the issue of synchronization. For years, they typically have synchronized their Unix servers very efficiently and very effectively. However, as a percentage of total computer population, the typical PC now far outnumbers the server class hardware. Therefore my idea of using an atomic watch type Real Time Clock (RTC) for GDT mostly addresses the issue of designing and manufacturing such an accurate clock which, like the servers, will also be able to tie in to time coordinating services. However, both the hardware and access to a time coordinating source must also be affordable in an environment where PC's are available for "free". Some of the available time coordinating code, especially that coming from GPS satellites, is far too complex to be useful in these cheap PC environments, so some effort will also have to be made to get systems like GPS to include the simpler GDT date/time code.

Synchronizing all computers over the network is of course possible and encouraged. However, if these very inaccurate clocks remain standard on PC's and as more PC's hook into the network for e-Business transactions, where the requirement for synchronization to plus or minus one second is not unusual, the overhead to correct for as much as 15 seconds daily drift in these PC's would be much greater in cost than putting in an accurate "atomic time" clock in each computer in the first place. Letting synchronizing software run in the background is not realistic solution either except here in the US where we probably waste as much electricity as the rest of the world uses. In most other countries, especially developing countries that are now becoming important partners in the emerging global e-Business economy, PC type computers are turned off at the end of the workday. When these computers are turned back on they immediately need to be able to pick up a good time signal to get back into synchronization, hence the need for such a signal in GPS satellites.

I have also received comments that a date/time standard, ISO 8601, already exists. Efforts like ISO 8601 to solve the Date/Time communication issue have been made, but why have a standard specifically for the interchange of computer dates and time when the inherent strength of a computer is translating any date format into an internal computer standard and vice versa. As far as I know, no computer carries an internal ISO 8601 format. Computers more typically use an internal clock, not unlike what I am proposing. The problem is that every computer manufacturer uses a different system and all those systems look at date and time as separate issues. This is not correct, as I shall detail shortly. However. where required, separating date and time from the proposed GDT standard is not a technical issue.

The next argument I have heard most often is that date and time are not to be combined in any standard. The inseparable aspects of date and time, while such an important concept in business, and even in the military, does not seem to affect our day to day lives, and therefore the assumption is made that date and time should always be kept separate because we typically know when we get out of bed in the morning what date it is. In a business transaction, however, the fact that the people dealing with the transaction have this inherent understanding is not good enough. Business transactions require that time be specified in no uncertain terms and that requires that time be specified as to a date.

While I agree wholeheartedly with the many comments that I have received stating that existing methods for communicating dates and time work fine, let me illustrate my perspective with yet another analogy, stating that I am glad that people like Gottfried Daimler put a roof over my "bicycle" because, when it gets cold here in Ohio or when it rains, that roof keeps the heat in and the rain out and makes my trip to work so much more practical than what it would have been 100 years ago or even 45 years, in Holland, when I had to ride my bicycle or walk.

GlobalDateTime is like putting a "roof" on the existing date and time methodologies. One can look at GlobalDateTime also from the perspective of scaffolding. My ideas build on the existing ordinal date concepts, like the Pick Internal Date and the firmware date/time in the IBM AS/400 and the Mac. Someone else will eventually build on top of the combination of these ideas after GDT has evolved as a global internal date/time standard. Therefore this kind of change does not mean that existing ideas are no good. On the contrary, those ideas are good enough to support the layers of "scaffolding" that future generations will add, just as people like Daimler built on the existing bicycle and carriage concepts.

GDT like implementations of "internal" and "external" dates are by no means new. They have existed for 35 years and, because of their nature, systems using ordinal internal dates are not subject to typical date rollover related problems like those that may have happened on 01JAN2000 and 29FEB2000. The stability of a system using internal dates and the applications completed on such a system, if implemented correctly, rely only on the internal format. External formats are derived from so-called metadata, which is like a (language) dictionary translation. As in a dictionary even though the translation might be wrong, that does not change the meaning of the original word. So also if in an internal date driven system the metadata and hence local presentation is wrong, that does not affect the stability of the actual system date/time in its internal format nor the application data that is written to disk or accessed from disk, in that internal format.

There are other systems, such as the IBM AS/400 and Apple Mac that use ordinal number derived dates. Since typical applications on those systems use the translation derived format, these systems are also subject to date rollover problems.

Because of metadata translations, transitions to GDT are relatively easy. GDT can initially be implemented in the OS software so as not to require the GDT specific RTC chip first. Transitions are further simplified because of metadata translations. Existing data can be referenced and modified with existing date formats while new, or selected new data uses the GDT date/time conversion formats. Again this is possible because of the stability of the internal date system, which stability is totally independent of the metadata.

For further information please contact:

Henry Keultjes
MD-Linux Scientific
Mansfield Ohio USA
Voice 419-525-1111
Home (After 10:00 GMT) 419-756-0527

PS: Because humans can relate to a location on a map, I like to suggest that the meanings of GET and GDT be combined into Greenwich Date/Time!