Location: PHPKode > scripts > AtomicTime > atomictime/mlGlobalTradeTime.html
 <TITLE> Global Date Time for E-Business Concept, rationale and implementation.</TITLE>

<H1> Global Date Time for E-Business Concept, rationale and implementation.</H1>

<H2>Henry Keultjes,
MD-Linux Scientific,
Mansfield Ohio USA
<A HREF="hide@address.com">hide@address.com</A></H2>v1.0, 18 July 2001
<EM>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.</EM>
<H2><A NAME="s1">1. Global Date Time for E-Business Concept, rationale and implementation.</A></H2>

<P>GDT is a globally uniform method for computers and computer software to relate date and
time elements to other computers and application software.
<P>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.
<P>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
<P>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
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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).
<P>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:
<P>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. 
<P>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.
<P>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
<P>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.
<P>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 ??
<P>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.
<H2><A NAME="s2">2. Comments to GlobalDateTime for e-Business</A></H2>

<P>Greenwich Electronic Time was established at Greenwich, England at the end of 1999.  With
that action, the GET-Time organization - see 
<A HREF="http://www.get-time.org">http://www.get-time.org</A> - 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
<P>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.
<P>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.
<P>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
<P>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
<P>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.
<P>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.
<P>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. 
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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.
<P>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
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
<P>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!
Return current item: AtomicTime