headers
Boruch Baum | 4 Jun 2012 17:02
Picon
Favicon

[tz] tz abbreviations / zdump for programmers


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.
(Continue reading)

Permalink | Reply | 30 comments |
headers
Paul Eggert | 4 Jun 2012 19:00
Favicon

Re: [tz] tz abbreviations / zdump for programmers

Thanks for the email.  Some comments:

> 2.2] zone.abbr.tab proposal

This seems better, since the file could be maintained automatically
from the existing data, with a new script or whatever.  I didn't
understand this table's "localedef" column though; isn't the tz
info independent of locale?  Or are you anticipating a future feature
in which time zone abbreviations depend on locale?

> int zdump(               /// returns TRUE on success, FALSE on failure

How about instead having a little function
that, given a time, finds the next (or the previous) transition time?
That would allow iterations through transitions that'd be much easier
than poring through the output of the proposed 'zdump' function, with
no need to worry about malloc and free.
Permalink | Reply | 9 comments |
headers
Boruch Baum | 4 Jun 2012 19:59
Picon
Favicon

Re: [tz] tz abbreviations / zdump for programmers


On 06/04/2012 11:36 AM, Steffen Daode Nurpmeso wrote:
> Boruch Baum <boruch_baum <at> gmx.com> wrote:
> 
> |My current plan is: |[.] |tzinfo    { |    time_t start
> /// seconds from epoch |    int    utc_offset    /// in minutes, or
> maybe seconds. |    char   is_dst        /// 0/1
> 
> I would suggest to you using a different field for that, which, if 
> not 0, would implicit mean "is daylight saving". We have a
> 'save_secs' field instead, meaning the time to save in seconds (we
> only use seconds, also in our utf_offset, which thus refers to the
> unadjusted offset).  Sometimes nice.
Accepted: utc_offest in seconds and is_dst changed to save_secs
Thanks.

> 
> |    char[] tz_abbrev     /// |    const char end_mark  /// '\0'
> 
> Ah, and we have a hashmap of all possible zone abbreviations, and 
> only store the index of it in our "RuleDat".
I don't see this hashmap. How can I find it?
Permalink | Reply | 0 comments |
headers
Boruch Baum | 4 Jun 2012 20:39
Picon
Favicon

Re: [tz] tz abbreviations / zdump for programmers


On 06/04/2012 01:00 PM, Paul Eggert wrote:
> Thanks for the email.  Some comments:
> 
>> 2.2] zone.abbr.tab proposal
> 
> This seems better, since the file could be maintained automatically
> from the existing data, with a new script or whatever.
OK.
> I didn't understand this table's "localedef" column though; isn't 
> the tz info independent of locale?  Or are you anticipating a 
> future feature in which time zone abbreviations depend on locale?
I'm not terribly certain, since I'm new to this myself. My
considerations / fears were:
1) having a way to know how the 'owners'/residents of a timezone
   format their time/date information.
2) multilingual zones - eg. Do the French in Quebec have the same
   TZ name and abbreviation as the Anglos there?
2) multi-character set zones - eg. Israel, where both Arabic and Hebrew
   are official languages (and English isn't) - Do the locals use
   their native character set representations of the timezone
   abbreviation and name? I would want to respectful of that, to the
   extent possible. In the case of Israel, I remember dst referred to
   only as שעון קיץ.

BTW, I made one important omission in my proposal for zone.abbr.tab -
I left out a field for the tz_name (eg. Asia/Baku).

Also, for the parochial need of my libhdate collection, it would be
useful to also include on each zone.abbr.tab line the coordinate
(Continue reading)

Permalink | Reply | 7 comments |
headers
Zefram | 4 Jun 2012 21:15

Re: [tz] tz abbreviations / zdump for programmers

Boruch Baum wrote:
>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).

This seems the wisest course, if you're committed to accepting
abbreviations on input.  You can automate the trawl through the
tzfiles, to pick out the abbreviation meanings that are relevant to
your application.  Run the program once, each time tzdata is updated.
Then when your application gets an abbreviation as input you do just
one quick lookup in the table that you generated.

For any more general approach to using abbreviations as input,
each specific application still needs to determine its own approach
to disambiguation.  Maybe it must provide some disambiguating hints,
such as a range of years or a continent.  Maybe ambiguities should be
resolved by asking a human.  Also, there's fundamentally more than one
thing you can do with an abbreviation as input: do you want to determine
a specific geographical timezone, or just an offset?  It all depends
on the application.  So it's not awfully feasible to provide one table
that's applicable to most users of abbreviations.

Have a look at <https://metacpan.org/release/App-olson>, a querying tool.
See what you make of the output from queries like "olson list i <at> now
o <at> now".  It doesn't support searching for an abbreviation anywhere in a
time period, but I'm intending to add that in the future.  I think some
tool like this would be of benefit to abbreviation users.

-zefram
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ángel González | 4 Jun 2012 22:45
Picon

Re: [tz] tz abbreviations / zdump for programmers

On 04/06/12 17:02, Boruch Baum wrote:
> 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).
I would ask the user.

Yes, the users are stubborn and will expect "your silly app" to "perfectly
know" what is, for instance, "PST timezone".
I'd throw them a dialog requesting clarification if they mean
-  Pacific Standard Time, UTC−8:00
-  Pakistan Standard Time, UTC+5:00
-  Philippine Standard Time, UTC+8:00

Maybe with a "By PST I always mean this one" checkbox.

If you try to guess, you will sometimes "guess wrong", and a smart program
taking bad decisions is worse than a dumb program you need to guide.

Also, in the example above you will discover that English is official
language in the three countries... :-)
(Continue reading)

Permalink | Reply | 16 comments |
headers
Paul Eggert | 5 Jun 2012 01:43
Favicon

Re: [tz] tz abbreviations / zdump for programmers

On 06/04/2012 11:39 AM, Boruch Baum wrote:
> Do the French in Quebec have the same
>    TZ name and abbreviation as the Anglos there?

Yes, absolutely.  This is a common situation
in many parts of the world.
Permalink | Reply | 6 comments |
headers
Tobias Conradi | 5 Jun 2012 02:23
Picon

[tz] time zone abbreviations - French vs English

was: tz abbreviations / zdump for programmers

On Tue, Jun 5, 2012 at 1:43 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 06/04/2012 11:39 AM, Boruch Baum wrote:
>> Do the French in Quebec have the same
>>    TZ name and abbreviation as the Anglos there?
>
> Yes, absolutely.  This is a common situation
> in many parts of the world.
That was someone without giving evidence, it follows Tobias with
giving evidence.

No they don't universally:

HNE vs EST
https://www.google.com/search?q=19h00+%22HNE%22+site%3Aqc.ca

Two other pairs are:
HAEC vs CEST
HEC vs CET

--

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Inglis | 5 Jun 2012 04:59
Picon
Picon
Picon

Re: [tz] tz abbreviations / zdump for programmers

On 2012-06-04 17:43, Paul Eggert wrote:
> On 06/04/2012 11:39 AM, Boruch Baum wrote:

>> Do the French in Quebec have the same
I am sure Paul read this as "different"^
>>     TZ name and abbreviation as the Anglos there?

French in New Brunswick (officially bilingual like Canada) and the rest 
of Canada would also use the same abbreviations and names.

> Yes, absolutely.  This is a common situation
> in many parts of the world.

Canadian English and French Time Zone Abbreviations and Names

PST/PDT Pacific S/D Time  HNP/HAP Heure Normale/Avancée du Pacifique
MST/MDT Mountain     "    HNR/HAR "			des Rocheuses
CST/CDT Central      "    HNC/HAC "			du Centre
EST/EDT Eastern      "    HNE/HAE "			de l'Est
AST/ADT Atlantic     "    HNA/HAA "			de l'Atlantique
NST/NDT Newfoundland "    HNT/HAT "			de Terre-Neuve
Permalink | Reply | 5 comments |
headers
Steffen Daode Nurpmeso | 4 Jun 2012 17:36

Re: [tz] tz abbreviations / zdump for programmers

Boruch Baum <boruch_baum <at> gmx.com> wrote:

 |My current plan is:
 |[.]
 |tzinfo    {
 |    time_t start         /// seconds from epoch
 |    int    utc_offset    /// in minutes, or maybe seconds.
 |    char   is_dst        /// 0/1

I would suggest to you using a different field for that, which, if
not 0, would implicit mean "is daylight saving".
We have a 'save_secs' field instead, meaning the time to save in
seconds (we only use seconds, also in our utf_offset, which thus
refers to the unadjusted offset).  Sometimes nice.

 |    char[] tz_abbrev     ///
 |    const char end_mark  /// '\0'

Ah, and we have a hashmap of all possible zone abbreviations, and
only store the index of it in our "RuleDat".  Less compact, but
one can store the string somewhere nearer as necessary.
(Due to filename length issues and data compactness we've used
a single binary database approach.)

Just my one cent.

--steffen
Forza Figa!
(Continue reading)

Permalink | Reply | 1 comment |

Gmane