Re: Getting Back to Basics - How to describe Dates and Times andEvents.

[g1smd@freeuk.com (Ian Galpin)]

On 2001-Apr-09 Todd Boyle <tboyle@rosehill.net> wrote in <ebXML-core>:


> Yes, as you said, I drop all of the specifically-named
> date and accounting period elements from my General Ledger
> schema... and substitute the following model:

> <transactionDate>
>   <qualifier>AnyEdifact2005qualifier</qualifier>      (optional)
>   <date>yyyy-mm-dd</date>       (required)
>   <time>hh:mm:ss</date>         (optional)
>   <timezone>zz</timezone>       (optional)
> <transactionDate>



[2001-Apr-16]


A minor point, but 'zz' is not enough for TimeZone.

ISO 8601 allows    +HH   -HH   +HH:MM   -HH:MM   +HHMM   -HHMM

Please note that there are a number of countries that have local time which
is  "xx and a half, hours" away from UTC (eg India). I believe that there
are also one or two others (also in Asia, or Pacific) that run on  xx:15  or
xx:45  difference to UTC. This is why there are four digits allowed in ISO
8601 - not all time zones are aligned  xx:00  with respect to UTC.

So, you really need room for a sign and four digits, with an optional colon
separator. The sign often also has a hidden meaning for the  00:00  time
zone. A zone of '+00:00' is for someone who is really in that zone. A zone
of '-00:00' is for a computer located elsewhere, but wishes to maintain all
their transactions in UTC (I hope I got those round the correct way). This
method isn't really officially defined anywhere... but it's mentioned on the
Web Page located at:
<http://serendipity.magnet.ch/hermetic/cal_stud/newman.htm>  for example.


What assumption is made about a date with no time zone? Is it local, or UTC
based? During much of the US evening, the date in Europe is already one day
ahead. Could a date be specified, WITHOUT a Time, but WITH a Time Zone? I am
writing this message, in the UK, at 2001-04-16 01:00 UTC (02:00 Local). Any
reply from the Eastern US states written in the next few hours will come
back dated 2001-Apr-15, seemingly before I actually wrote it, unless you
take account of the Time Zone difference. For a transaction, can EDI cope
with an order being shipped before it was received, as that may be what the
computer records (if based only on Date, without clarification of Zone)
would appear to say? For these reasons, many people (eg Astronomers and Ham
Radio operators) gave up with Time Zones many years ago - they normalise all
work to UTC.



>   <time>hh:mm:ss</date>         (optional)

A minor typo was spotted:   </date>  should be  </time>  I think.



I think that it is very important when defining data types that sufficient
thought is given to the full numeric range that will be required. We had the
'Year 2000 Problem' simply by restricting the Year Field in dates to only
two digits. Bar-coding of products is running into problems because the
current system allows only 99 countries, 100 000 companies per country, and
100 000 products per company. As for telephone numbers, we are always
running out (at least in the UK) every few years, and having to redesign the
system. The only system that seems to have loads of thought applied is in
the SIM Card Serial Number in a Digital Mobile Phone. It's 20 digits long,
allowing everyone on the planet to have a new phone every month for several
centuries before the numbers have any chance of repeating. I think those are
the real basics that a designer should address. Any new scheme is no good if
the number space is insufficient.



Cheers,

Ian.


<g1smd@freeuk.com>


[2001-04-16]

.end