quality of historical zone information

INFOMAN Inc. mpereira at istar.ca
Mon Jan 29 18:52:43 UTC 2001

This is a generic issue in many standards.  For some "three months", see
below is "historical". For others, the past year is contemporary. Working in
Open-edi standardization (JTC1/SC32/WG1), security services(JTC1/SC27) as
well as the area of geomatics (ISO TC 211) from an e-commerce, e-business,
e-gov't, etc. standardization perspective, I would welcome input, ideas,
etc. on some common agreement as to what we mean by "contemporary",
"historical", "archival", etc.. Being involved in logistics, I not only have
to know and record the local time/date to UTC (or vice-versa), I also have
to be able to support "records retention" requirements of the jurisdictions
in which I do business. Working in a complete electronic/digital mode, I
keep records of completed business transactions only as long as I am legally
required too, (e.g.  via an automated time zone driven deletion routines).

Can we, should combine our needs, efforts here into a new standard?

Gwillim is absolutely right when he says that this is too much work for any
one person (no matter how expert).

looking forward to feedback, ideas - Jake Knoppers (Canada)

> -----Original Message-----
> From: Gwillim Law [mailto:gwil at mindspring.com]
> Sent: January 29, 2001 1:20 PM
> To: tz (E-mail); alois at astro.ch
> Subject: Re: quality of historical zone information
> Alois Treindl wrote:
> > Defining more zones will not be enough.
> > it must be possible to associate every populated place with the right
> > zone.
> That's a requirement for my work, too.  I have been working in
> the field of
> logistics.  To track shipments, I need to be able to convert from
> local time
> to UTC, based on location.  That means I have to know the historical
> sequence of UTC offsets for each possible location.  The
> difference between
> my application and astrology is that I'm concerned with a much narrower
> range of dates:  typically from today minus three months to today
> plus three
> months, although for archival purposes I may want to look back several
> years.
> If the membership of the tz list, or any other group, wants to
> undertake to
> create and maintain a more complete tz archive that would do
> justice to the
> geographical aspect, I have a few principles to suggest.
> Too much work is involved to expect any one person, especially a
> volunteer,
> to do it all.  There's a natural way to subdivide it:  by countries.  In
> general, time zones are determined by legislation which applies
> throughout a
> jurisdiction, almost always a whole country.  In many cases, a volunteer
> could take responsibility for several countries or a whole region.  On the
> other hand, a country with a very complex time zone history, such as the
> United States, might be divided up among several volunteers.
> Ideally, each
> volunteer would be acquainted with the languages and culture of the region
> he or she is responsible for.  Uniform guidelines should be drawn up,
> covering things like database design, data authentication, and update
> notification.
> Database design:  The current tz archive has an implicit database design,
> which is implemented in various Posix-compliant systems.  This existing
> design is inadequate for some purposes.  For example, Brazil is
> divided into
> areas that observe four different standard times.  The information about
> which state is in each area is hidden in the comments.  If a new database
> design allows the geographical component to be represented, Posix systems
> should be supported as a legacy.  This might be done by taking a slice or
> subset of the data.  Other systems might choose to take a different slice,
> in order to tailor the data to their specific requirements and save on
> storage.  A logistics application might select only post-1996 data, having
> no need to refer further back than that.
> Data authentication:  the data in the existing tz archive were
> acquired from
> several sources.  They're cited in the comments.  They include Shanks,
> Whitman, IATA, and personal communications from a number of Time Zone
> Caballeros.  None of these are really primary sources.  Primary sources
> include laws, acts, and decrees reported in the Congressional Record,
> Hansard, etc., and newspaper reports of actual time zone
> implementation.  We
> do have some primary sources, but they don't cover the whole world.  When
> several sources disagree (and we don't have a primary source),
> someone like
> Paul Eggert decides which is the most reliable, and explain his
> decision in
> the comments.  As new sources become available, some of the old decisions
> may have to be reconsidered.  What we need is a file containing every
> available document that has clues to historical time zone data.  This file
> could be partitioned by country or region, so that each time zone
> volunteer
> saves only those documents pertaining to his or her specific area.
> Guidelines should cover criteria for selecting the most reliable
> information
> from a set of documents, as well as the maintenance, back-up, and public
> availability of the source material.
> Update notification:  Some updates to the expanded tz archive would be to
> correct old errors.  Others would be to extend time zone rules
> further into
> the future.  Currently, all updates to the tz archive affect all
> users, and
> are reported to the tz mailing list.  Would this still be sufficient?  It
> would be a great help to maintain a Web site that displays all the tz
> archive data in a format easily understood by casual users.  For
> one thing,
> more people would be able to find mistakes in the data and send in
> corrections.  Perhaps Web pages could be automatically generated
> by applying
> a transformation to the archive.
> The work I've described above would be a valuable service to the Internet
> community.  Is there some way to finance it?  For example, could certain
> beneficiaries be persuaded to subsidize it?  Could advertising be sold on
> the Web site?  If so, the volunteers could be paid, and the
> archive could be
> more effectively improved.
> Yours,    Gwillim Law

More information about the tz mailing list