GlobalDateTime (GDT) for issues related to 3.2

Greetings:

Priscilla Walmsley suggested that I submit this article, - originally
published in 1999.  Please take your time reading through this because it is
important to understand the "setting the stage" issues and the comments that
may at first seem irrelevant.  Like the fact that GDT *is* UTC but is also
*more* than UTC and that GDT is designed for the convenience of the
transaction people that use the software that people like yourself write to
make their life easier.  Yes, making the user's life easier, that's what both
programming and GDT are all about.

Henry



GlobalDateTime (GDT) for e-Business.  Concept, rationale and implementation.

By Henry Keultjes

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 specified 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, time also depends on the time zone where the
24-hour clock starts.  Therefore business contracts require that a time zone
like EST or EDT be specified.

As more and more business is contracted with parties 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 has long been used to coordinate sea and
air navigation and to a lesser extent, in the past at least, global business
transactions.  While logic would have dictated GDT be based on the IDL,
precedent favors the zero meridian for coordinating global business
transactions and that same fact of the IDL and UTC being seperated by half a
day favors GDT as a solution to the inherent confusion.

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, except at 12:00 (on a 24:00 clock) always spans two
dates.

GDT solves this dual date/time dilemma by providing the systems environment in
which e-Business can be transacted within a global date/time frame while the
transaction people, on either end, continue to interact with their
transactions not only on the local date/time but also while using their own
local cultural date/time format.

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.  (Where needed, greater precision than
seconds can be implemented.)


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 GDT proposes that 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 socalled firmware and the Operating
System (OS) software translate that internal date/time format into local
date/time presentation.  It is this "external" presentation that computer
users will see, typically in the corner of the screen, and as 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
Greek??
Hijra??
Chinese ??
Japanese??
Russian?
etc

All e-Business protocols can use this 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.

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
http://www.get-time.org - validated the need for a global e-Business time
standard but did not offer a solution, only an idea.  GET-Time did however
validate my four year effort to establish as a standard a mdRDBMS
(milti-dimensional RDBMS) 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, except where such involvement seems contrary to smoothing
relations between other European countries, especially France.

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 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.  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 and Customer Relationship Management (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 techies also disagree with me on the issue of synchronization.  They
typically have their Unix servers which they have synchronized, very
efficiently and very effectively, for years.  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 and Galileo to include the simpler GDT date/time code.

Synchronizing all computers over the network is of course possible and
encouraged but, 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 were 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 work day.  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
Galileo and 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 of course been laudable.  But it is weird that a standard like ISO 8601
was established specifically for the interchange of computer information when
the inherent strength of computers is translating, from the inherent
instruction set of the processor into whatever, including the ability to
input any date format and translate it into a computer carried 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 except every computer manufacturer uses a different system and
all those systems look at date and time as separate issues which 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 Louis Citroen 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 Citroen
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 more than 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 socalled
metadata which is like a (language) dictionary translation.  As in a
dictionary, even though the translation might be wrong which 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, like the IBM AS/400 and Apple Mac that use
ordinal number derived dates but typical applications on those systems
use the translation derived format in applications and therefore these
systems, while having the ability to avoid problems, applications that
run on those systems are 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
Microdyne Company
Mansfield Ohio USA
Voice 419-525-1111
Home 419-756-0527

Received on Friday, 31 January 2003 22:08:20 UTC