[tz] tz abbreviations / zdump for programmers

Boruch Baum boruch_baum at gmx.com
Mon Jun 4 15:02:10 UTC 2012

Hash: SHA1

Greetings y'all,

I have a bit of a long (inaugural) post here to describe my interest
in joining this list, and what I might be able to contribute to the
greater glory of tz-correctness. BTW, as part of my 'due diligence'
before posting this, I read/scanned a selection of the collection of
detailed comments in the glibc-2.13/timezone files, as well as the
timezone entry in glibc-2.13/FAQ. I'm very glad those comments are there.

1] The app/library I develop/maintain
2] End users' stubborn insistence on using tz abbreviations
2.1] zone.tab modification proposal
2.2] zone.abbr.tab proposal
3] The 'zdump' programmer's function I 'need' to write

1] The app/library I develop/maintain
libhdate is a FOSS collection for Hebrew time/date 'stuff', for which
time zone data and location coordinates are important because: 1) we
have about a dozen significant astronomical times-of-day that need to
be mapped to a correct local clock time at any particular location; 2)
users want that information for future and past dates, and; 3) users
want that information for locations in other parts of the globe.

This FOSS collection is under active development and versions are
available from sourceforge and the Debian GNU/Linux repositories.
There are unrelated, closed-source, alternatives available (eg.
kaluach for windows and java, and dostagfarlinux for, um, linux).

2] End users' stubborn insistence on using tz abbreviations
... and who can blame them, when that's all they hear in the media.
This leaves me in a bind, because if I accept a tz abbreviation as a
user input, I have two undesirable options: 1) I could scan ALL the
~420 tzif files for matches and, if I discover that the tz abbrev is
not unique, either make an educated guess (based upon the user's
locale definition which often will include a country code and a
language) or prompt the user for clarification; or 2) I could
pre-compile a list that suits my parochial needs, and update my list
anytime the tzdata package is updated (and still have to occassionally
guess or prompt the user).

Then I said to myself, "self, you can't be the only one out there
facing these users - go consult and find a global solution".

Following are two proposals. Neither may be perfect, but each may make
life alot easier for many...

2.1] zone.tab modification proposal
Add a new column/field to this file, in the format:
   xxx    is a tz abbreviation
   nnnnn  is the UTC offset for that abbreviation.
The use of ";", ":", and braces are to simplify the task of parsing
the data programmatically.

1) All information for a timezone on a single line
   (ie. in a single record).
2) All worldwide information in a single file (no need to travel the
   dir-tree and parse ~420 files)
1) Long line(record) length
2) Messing with the format of an existing file, upon which others may
3) Requires change to whatever script/program is used to compile the
   file for release

2.2] zone.abbr.tab proposal
Create a new text file, say /usr/share/zoneinfo/zone.abbr.tab, sorted
by tz abbreviation, with a format like:
   localedef        useful for setting $LC_TIME
                    and for language matching
   is_dst           if yes, this would have the abbreviation
                    of the non_dst version of this tz.
   historical_only  (y/n) - ie. whether currently in use.
   full_name        of the abbreviation, not of the 'real' tz name.

1) Easy to find matches for users' pesky (short and convenient-to-type)
2) All worldwide information in a single file (no need to travel the
   dir-tree and parse ~420 files)
3) Includes additional useful information (is_dst, historical_only,
   full_name, locale_def)
4) Doesn't mess with existing files
1) It's a new file.
2) Requires new script/program to compile the file for release

3] The 'zdump' programmer's functiion I 'need' to write
This section isn't directly related to the above. I don't NEED to
write a 'zdump' programmer's functiion; I WANT to, because I remember
when a 4Mhz clock speed was wicked fast, and using the current glibc
time functions for my libhdate collection would be tremendously
wasteful, although today's users will probably never notice.

For this section, the reason I want to consult with members of this
list (and I appreciate you having read this far) is to make the
function as universally useful as possible (it will be FOSS/GPL3+) .

My current plan is:

int zdump(               /// returns TRUE on success, FALSE on failure
    const char* tzname,  /// fully-qualified time-zone name
                         ///    (eg. Asia/Baku)
    const time_t start,  /// seconds from epoch to be scanned
    const time_t end,    /// seconds from epoch to be scanned
    int* num_entries,    /// upon successful return, int will contain
                         ///    the number of dst transitions + 1,
                         ///    for the interval 'start' to 'end'.
                         ///    The first entry will always be the
                         ///    tz state at time_t start.
                         ///    Returns 0 on failure.
    void* return_data    /// upon successful return, will contain a
                                pointer to a malloc()ed space of
                         ///    'num_entries' of 'tzinfo' data, as
                         ///     described below, sorted in ascending
                         ///     chronological order.
                         ///    Returns NULL on failure.

tzinfo    {
    time_t start         /// seconds from epoch
    int    utc_offset    /// in minutes, or maybe seconds.
    char   is_dst        /// 0/1
    char[] tz_abbrev     ///
    const char end_mark  /// '\0'
- -- 
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Version: GnuPG v1.4.12 (GNU/Linux)


More information about the tz mailing list