[tz] tz abbreviations / zdump for programmers
Boruch Baum
boruch_baum at gmx.com
Mon Jun 4 15:02:10 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
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.
CONTENTS
========
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:nnnnn;xxx:nnnnn;...;}}
where:
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.
Advantages:
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)
Disadvantages:
1) Long line(record) length
2) Messing with the format of an existing file, upon which others may
depend
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:
tz_abbrev
country_code
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.
utc_offset
historical_only (y/n) - ie. whether currently in use.
full_name of the abbreviation, not of the 'real' tz name.
Advantages:
1) Easy to find matches for users' pesky (short and convenient-to-type)
tz_abbr
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
Disadvantages:
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'
}
- --
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJPzM3HAAoJEDvrUfDmCx9LbJ4P/RMD+8KWkXxrLtpivyQVz6Yv
h88mWjwfeTpb7laT4yeg726YYUQEDfhueLFELRTpxR6aAIAW7fBZEu6UwEMSsxHe
UaQdx/xc/03aei/AG6z31u0C+arA40qs8twxEw5pdyHfvBxhQh0YOxO+dl01+zmg
w4Y+Mlyd72QmAZ+pdIc5l2L/nTh9L+YnlmPxsXoomYSTh+9kigOxS5JZVMu2sYy6
7FGMj+mybrtru12qwJmoFG2hNjVgy0zKSuJ1HOXmqi5JKBNthlsfkyV4E9vzSGWC
PkkbI8R0adGnqKa9faHQxFG+jV+K5Fjscr3eabBi8IYHG+cGYOL6vD0KkNFbHRQf
wLRGpkkMjoJm9cxJ7f17wcQFtYFKjcDLIqqtDuT7LhHJ7iF2x4lTqd4YjvpA6rqN
fcD+4TNfm8Na5bNbKNJqvWy+Od46wSNqFOiUf9NQaWsUZx/yiXjw1Sl4Jqi7/2Sg
A3rc2bcw02Co80bWA+lsMbZUL5NJlQAdfWCKe7xafdILX8PPbe0CaTHzNUFd4vR9
70AJsq6teBivVHossldNlQfsK+S4HmcSMGPt1AuANjGUv0ZoCveR71Ewt0D2wbi4
hSEaSI/P3MVSsFRMJZIoMXlFTuF6d6qItoRvmHrLdU2u5f1+Kjbt7tH0eMOrcdm9
BUi/N3QtrJkU6vWXjLal
=n4Kd
-----END PGP SIGNATURE-----
More information about the tz
mailing list