January 2009 - tz - lists.iana.org

Australian timezone abbreviations
by Ted Percival Jan. 12, 2009

Jan. 12, 2009

Paul Eggert wrote: > I'd like to hear more from Australian correspondents on this before > thinking about specific changes, though. +1 me for changing to AEST, AEDT and so on. I encourage you to read through a relatively recent discussion about this. I straw-polled our Unix users' group's mailing list: http://lists.humbug.org.au/archives/general/2008-April/thread.html#26929 . If you'll excuse the deviation to a discussion of whether various places should have daylight saving time, you'll see a preference for AEST: I count 6 for and 1 possibly against. Eric Ulevik wrote: > ABC NewsRadio have been referring to 'Eastern Standard Time' and > 'Eastern Summer Time'. "Australian" is presumed for an Australian radio broadcast; for computer use there is no regional context. At any rate, the discussion should focus on the *abbreviations* rather than the full names because only the abbreviations are specified by the timezone database. I'm not convinced that searching the web for "EST" is a valid survey, particularly as it is a common abbreviation for "estimate" or "established". There are also websites such as Flickr that use EST but there is evidence that this is simply a result of using the timezone database: a feedback loop. I wonder to what extent the timezone database is seen as an authority for what people use. -- Ted Percival http://tedp.id.au/tzdata-au/

1 0

"Military" time zones
by Paul Eggert Jan. 10, 2009

Jan. 10, 2009

msb(a)vex.net (Mark Brader; please reply accordingly) writes: > As you would know, there is a system of "military" time zone > designations where zones are identified by a single letter: > http://www.timeanddate.com/library/abbreviations/timezones/military/ > gives letter equivalents for zones from -12 = Y to +12 = M. > > I was having an email conversation with Russ Rowlett, who maintains > the units-of-measurement site at <http://www.unc.edu/~rowlett/units/>, > and we were wondering whether these single-letter designations are > actually still used in practice -- and, if so, how time zones above > +12 or not on integer hours are represented. Is there an official > reference for current practice on this anywhere? Yes, please see the Combined Communications-Electronics Board general communication instructions, dated 2007 <http://www.jcs.mil/j6/cceb/acps/acp121/ACP121H.pdf>. These are authoritative for the armed forces of Australia, Canada, NZ, the UK, and the US. Briefly: "N" is also used for UTC+13, "to provide for a ship in zone -12 keeping Daylight Saving Time". There's no official provision for UTC+14, but I presume that'd be "O". For DST, use the corresponding next letter (e.g., the eastern-US "R" becomes "Q" during DST.) As for non-integer hours, the instructions simply say: "For time midway between zones, both letters are used."

2 1

Time Zone y Chihuahua Mexico
by Marco Antonio Bravo Grajeda Jan. 8, 2009

Jan. 8, 2009

Chihuahua has a different time zone than the center of Mexico, please correct this.

1 0

timezone code - re-entrancy issue
by John Dlugosz Jan. 7, 2009

Jan. 7, 2009

At the bottom of localsub, tzname[tmp->tm_isdst] = &sp->chars[ttisp->tt_abbrind]; I think this is to update the tzname string to the last time zone abbr. actually used in to produce the tm values. It is not re-entrant. This is called even by localtime_r, which may be changing the values even as another thread (who called plain localtime) is reading it. It also changes all the time as the "binary search" is being done by mktime. That violates the "behaves as if never called" rule, and putting it in a subroutine doesn't help there. Am I missing something? --John

1 0

time zone library
by John Dlugosz Jan. 7, 2009

Jan. 7, 2009

I downloaded the timezone library, and in adapting it to my needs I've been figuring out how it works. I have a few questions, and also (hopefully) a contribution. First, my contribution. Regarding /* ** Adapted from code provided by Robert Elz, who writes: ** The "best" way to do mktime I think is based on an idea of Bob ** Kridle's (so its said...) from a long time ago. ** It does a binary search of the time_t space. Since time_t's are ** just 32 bits, its a max of 32 iterations (even at 64 bits it ** would still be very reasonable). */ I'm using 64-bit time_t values, and find that it usually takes 62 to 64 iterations. Basically, it is always worst case. I tried using a rough guess for the initial hi and low: lo = ((yourtm.tm_year-70) * 365i64 + yourtm.tm_mon * 28) * SecondsPerDay; hi = ((yourtm.tm_year-70) * 366i64 + (yourtm.tm_mon+1)*31) * SecondsPerDay; when the resulting time_t would be positive, and it completes in 20 to 23 iterations. I punted on the negative case, but a very similar calculation would work. When tm_year < 70, I just used the smallest value I care about for lo, and 0 for hi. That gives me worst case 35 iterations, because I'm only supporting values back to 1752 CE, not the full range of a 64-bit number, which would be 21 times longer than the age of the universe. Now for my first question. TZ_MAX_TIMES is 1200, and that is exactly the length of the arrays for state::ats and state::types. I suppose it is noting every time change, e.g. DST adjustments twice a year for 600 years? There is no need to store anything before the first reported time in the configuration files, as it simply uses the first entry for anything older (no DST in pre-history); it seems to have code for dealing with dates beyond the end of the table. Does it extrapolate the current DST rule in the future? I'd like to cut off the table at a more reasonable date for my application. Where is that table populated? Is it when the data file is loaded, or in zic when it is created? My second question concerns leap seconds. It appears that the leap second data is associated with every zone file. Why isn't it simply the same for everything, and global? --John

1 0

FW: Oops - forgot to make sure the URL was clear
by Olson, Arthur David (NIH/NCI) [E] Jan. 5, 2009

Jan. 5, 2009

I'm forwarding this message from Dave Thewlis, who is not on the time zone mailing list (at least not at the address below). Those of you who are on the list, please direct replies appropriately. --ado From: Dave Thewlis [mailto:Dave.Thewlis@calconnect.org] Sent: Monday, January 05, 2009 5:33 To: Olson, Arthur David (NIH/NCI) [E] Subject: Oops - forgot to make sure the URL was clear Dear Arthur David, Thanks you very much for posting the invitation. However the URL about the workshop didn't come through clearly, so if you would, could you please add the following post to the TZ list: URL for the CalConnect Timezone Workshop Please see http://www.calconnect.org/timezoneworkshop.shtml for more information and to register. Thanks! Dave Thewlis -- Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis(a)calconnect.org

1 0

Patch to support --help
by Joseph S. Myers Jan. 2, 2009

Jan. 2, 2009

The tools zdump and zic support the GNU-standard --version option (output version information to stdout and exit successfully), but not the associated --help option (output usage and bug reporting information to stdout and exit successfully). This patch adds such support. tzselect supports neither option, so this patch adds support for both options to it. diff -ru tzcode.orig/tzselect.ksh tzcode/tzselect.ksh --- tzcode.orig/tzselect.ksh 2008-09-10 02:33:17.000000000 +0000 +++ tzcode/tzselect.ksh 2009-01-02 16:55:45.000000000 +0000 @@ -1,6 +1,6 @@ #! /bin/ksh -# '@(#)tzselect.ksh 8.1' +VERSION='@(#)tzselect.ksh 8.1' # Ask the user about the time zone, and output the resulting TZ value to stdout. # Interact with the user via stderr and stdin. @@ -45,6 +45,21 @@ exit 1 } +if [ "$1" = "--help" ]; then + cat <<EOF +Usage: tzselect +Select a time zone interactively. + +Report bugs to tz(a)elsie.nci.nih.gov. +EOF + exit 0 +elif [ "$1" = "--version" ]; then + cat <<EOF +tzselect $VERSION +EOF + exit 0 +fi + # Make sure the tables are readable. TZ_COUNTRY_TABLE=$TZDIR/iso3166.tab TZ_ZONE_TABLE=$TZDIR/zone.tab diff -ru tzcode.orig/zdump.c tzcode/zdump.c --- tzcode.orig/zdump.c 2008-09-10 02:33:24.000000000 +0000 +++ tzcode/zdump.c 2009-01-02 16:56:59.000000000 +0000 @@ -230,6 +230,17 @@ warned = TRUE; } +static void +usage(const char *progname, FILE *stream, int status) +{ + (void) fprintf(stream, +_("%s: usage is %s [ --version ] [ --help ] [ -v ] [ -c [loyear,]hiyear ] zonename ...\n\ +\n\ +Report bugs to tz(a)elsie.nci.nih.gov.\n"), + progname, progname); + exit(status); +} + int main(argc, argv) int argc; @@ -266,6 +277,8 @@ if (strcmp(argv[i], "--version") == 0) { (void) printf("%s\n", elsieid); exit(EXIT_SUCCESS); + } else if (strcmp(argv[i], "--help") == 0) { + usage(progname, stdout, EXIT_SUCCESS); } vflag = 0; cutarg = NULL; @@ -275,10 +288,7 @@ else cutarg = optarg; if ((c != EOF && c != -1) || (optind == argc - 1 && strcmp(argv[optind], "=") == 0)) { - (void) fprintf(stderr, -_("%s: usage is %s [ --version ] [ -v ] [ -c [loyear,]hiyear ] zonename ...\n"), - progname, progname); - exit(EXIT_FAILURE); + usage(progname, stderr, EXIT_FAILURE); } if (vflag) { if (cutarg != NULL) { diff -ru tzcode.orig/zic.c tzcode/zic.c --- tzcode.orig/zic.c 2008-09-10 02:33:18.000000000 +0000 +++ tzcode/zic.c 2009-01-02 16:57:40.000000000 +0000 @@ -156,7 +156,7 @@ const struct zone * zp, int ntzones); static void setboundaries(void); static zic_t tadd(zic_t t1, long t2); -static void usage(void); +static void usage(FILE *stream, int status); static void writezone(const char * name, const char * string); static int yearistype(int year, const char * type); @@ -454,13 +454,15 @@ } static void -usage(void) +usage(FILE *stream, int status) { - (void) fprintf(stderr, _("%s: usage is %s \ -[ --version ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\ -\t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n"), - progname, progname); - exit(EXIT_FAILURE); + (void) fprintf(stream, _("%s: usage is %s \ +[ --version ] [ --help ] [ -v ] [ -l localtime ] [ -p posixrules ] \\\n\ +\t[ -d directory ] [ -L leapseconds ] [ -y yearistype ] [ filename ... ]\n\ +\n\ +Report bugs to tz(a)elsie.nci.nih.gov.\n"), + progname, progname); + exit(status); } static const char * psxrules; @@ -498,11 +500,13 @@ if (strcmp(argv[i], "--version") == 0) { (void) printf("%s\n", elsieid); exit(EXIT_SUCCESS); + } else if (strcmp(argv[i], "--help") == 0) { + usage(stdout, EXIT_SUCCESS); } while ((c = getopt(argc, argv, "d:l:p:L:vsy:")) != EOF && c != -1) switch (c) { default: - usage(); + usage(stderr, EXIT_FAILURE); case 'd': if (directory == NULL) directory = optarg; @@ -561,7 +565,7 @@ break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) - usage(); /* usage message by request */ + usage(stderr, EXIT_FAILURE); /* usage message by request */ if (directory == NULL) directory = TZDIR; if (yitcommand == NULL) -- Joseph S. Myers jsm(a)polyomino.org.uk

2 2

Australian timezone on Linux
by Girish Hilage Jan. 1, 2009

Jan. 1, 2009

Hi, I have a problem setting the Australian DST timezone on my Fedora Core 8 system. When DST starts it is able to advance the time by an hour but the time does not wind back by an hour while DST ends. I am using timezone "South Australia". DST start : [girish@mymachine Australia]$ date Sun Oct 5 01:59:57 CST 2008 [girish@mymachine Australia]$ date Sun Oct 5 01:59:58 CST 2008 [girish@mymachine Australia]$ date Sun Oct 5 03:00:00 CST 2008 [girish@mymachine Australia]$ date Sun Oct 5 03:00:03 CST 2008 DST end : [girish@mymachine Australia]$ date Sun Apr 5 02:59:57 CST 2009 [girish@mymachine Australia]$ date Sun Apr 5 02:59:59 CST 2009 [girish@mymachine Australia]$ date Sun Apr 5 03:00:01 CST 2009 [girish@mymachine Australia]$ date Sun Apr 5 03:00:02 CST 2009 This is also not working for Apr 6 08. Is there any reason why is it not working properly? Regards, Girish DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

6 5