Right, sorry about the confusion yesterday - any ideas on the Pacific/Guam error? Also, I realise that it should be Africa/Madagascar (or Mauritius). It was near the end of the day for me and I think I was running on fumes. I'm currently in the process of writing a python parser for the data files - but I've just noticed that some of the lines are NOT tab delimited. Any ideas on this? Example: Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S Rule EUAsia 1979 1995 - Sep lastSun 1:00u 0 - Rule EUAsia 1996 max - Oct lastSun 1:00u 0 - ----------------------From this point on there's no tab between the word Rule and the zone name----------------- Rule E-EurAsia 1981 max - Mar lastSun 0:00 1:00 S Rule E-EurAsia 1979 1995 - Sep lastSun 0:00 0 - Rule E-EurAsia 1996 max - Oct lastSun 0:00 0 - Rule RussiaAsia 1981 1984 - Apr 1 0:00 1:00 S Rule RussiaAsia 1981 1983 - Oct 1 0:00 0 - Rule RussiaAsia 1984 1991 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1985 1991 - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1992 only - Mar lastSat 23:00 1:00 S Rule RussiaAsia 1992 only - Sep lastSat 23:00 0 - Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 - This occurs in a number of places and it makes writing a search algorithm a lot harder - I wonder if anyone has any input. Dan On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <dancotruta@linnoc.net> wrote:
Oh - and forgive the confusion above between Mauritius and Madagascar.
On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <dancotruta@linnoc.net>wrote:
Sorry, I should have also added this failure case:
[dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2009 Pacific/Guam Pacific/Guam -9223372036854775808 = NULL Pacific/Guam -9223372036854689408 = NULL Pacific/Guam Tue Dec 31 14:20:59 1844 UTC = Mon Dec 30 23:59:59 1844 ChST isdst=0 gmtoff=-51660 Pacific/Guam Tue Dec 31 14:21:00 1844 UTC = Wed Jan 1 00:00:00 1845 ChST isdst=0 gmtoff=34740 Pacific/Guam Mon Dec 31 14:20:59 1900 UTC = Mon Dec 31 23:59:59 1900 ChST isdst=0 gmtoff=34740 Pacific/Guam Mon Dec 31 14:21:00 1900 UTC = Tue Jan 1 00:21:00 1901 ChST isdst=0 gmtoff=36000 Pacific/Guam 9223372036854689407 = NULL Pacific/Guam 9223372036854775807 = NULL
Any ideas on how the t_time / int problem relates to this?
On Mon, Aug 11, 2008 at 4:57 PM, Dan Cotruta <dancotruta@linnoc.net>wrote:
Dear Olson,
Many thanks for your quick reply. I did go through the archives a little more carefully after sending my question. As I'm not a C programmer - can you just confirm my understanding of the problem?
time_t is part of a standard C library; on 64 bit systems it is defined as being 64 bits long, giving a very large range for the years that can be displayed. int is the standard builtin integer type, which for reasons that evade me is still defined as 32 bits long.
the tzcode does some fancy calculations to work out historical/future times of some kind - and obviously trying to fit a 64 bit value into a 32 bit space doesn't work.
I hope that's right so far...
So then:
Why does Madagascar fail? [dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2008 Mauritius Mauritius -9223372036854775808 = NULL Mauritius -9223372036854689408 = NULL Mauritius 9223372036854689407 = NULL Mauritius 9223372036854775807 = NULL
Here, the limit should be 2008 - therefore the 32 bit limit should not be a problem. Am I missing something?
I don't know anything about C programming - is this something that's likely to be fixed at some point soon? I've started work on a Python version of zdump to get around this limitation - is this something that might be useful to the community?
If so, I'd appreciate some help decrypting the logic of the tzdata files.
Thanks again for your swift reply,
Dan
On Mon, Aug 11, 2008 at 2:07 PM, Olson, Arthur David (NIH/NCI) [E] < olsona@dc37a.nci.nih.gov> wrote:
The numerical values are "number of seconds since midnight, January 1, 1970; they can be the immense values below on systems where time_t values are 64-bit entities. On such systems, extremely large and extremely small time stamps are associated with years that can't be represented in 32-bit integers, so we can't correctly convert them to "struct tm"s that represent them--that's why the NULLs pop out for these very small and very large values.
From: Dan Cotruta [mailto:dancotruta@linnoc.net] Sent: Monday, August 11, 2008 8:30 To: tz@lecserver.nci.nih.gov Subject: zdump
Someone, please enlighten me - what do the numerical numbers in the output of zdump stand for?
What I mean is, for this output:
[dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2008,2009 America/Los_Angeles America/Los_Angeles -9223372036854775808 = NULL <------ What does this line signify? America/Los_Angeles -9223372036854689408 = NULL <------ What does this line signify? America/Los_Angeles Sun Mar 9 09:59:59 2008 UTC = Sun Mar 9 01:59:59 2008 PST isdst=0 gmtoff=-28800 America/Los_Angeles Sun Mar 9 10:00:00 2008 UTC = Sun Mar 9 03:00:00 2008 PDT isdst=1 gmtoff=-25200 America/Los_Angeles Sun Nov 2 08:59:59 2008 UTC = Sun Nov 2 01:59:59 2008 PDT isdst=1 gmtoff=-25200 America/Los_Angeles Sun Nov 2 09:00:00 2008 UTC = Sun Nov 2 01:00:00 2008 PST isdst=0 gmtoff=-28800 America/Los_Angeles 9223372036854689407 = NULL <------ What does this line signify? America/Los_Angeles 9223372036854775807 = NULL <------ What does this line signify?
The number is far too large to be a standard timestamp, even in milliseconds... so what is it?
Many thanks, -- Dan Cotruta Operations Manager, London Innovation Centre.
Tel: 0203 006 7278 Mob: 0779 163 4020
London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP (T) 0845 262 8545 (F) 020 8481 0460 (e) info@linnoc.net (w) www.linnoc.net London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited. Registered in England under no. 4557707.
-- Dan Cotruta Operations Manager, London Innovation Centre.
Tel: 0203 006 7278 Mob: 0779 163 4020
London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP (T) 0845 262 8545 (F) 020 8481 0460 (e) info@linnoc.net (w) www.linnoc.net London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited. Registered in England under no. 4557707.
-- Dan Cotruta Operations Manager, London Innovation Centre.
Tel: 0203 006 7278 Mob: 0779 163 4020
London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP (T) 0845 262 8545 (F) 020 8481 0460 (e) info@linnoc.net (w) www.linnoc.net London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited. Registered in England under no. 4557707.
-- Dan Cotruta Operations Manager, London Innovation Centre.
Tel: 0203 006 7278 Mob: 0779 163 4020
London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP (T) 0845 262 8545 (F) 020 8481 0460 (e) info@linnoc.net (w) www.linnoc.net London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited. Registered in England under no. 4557707.
-- Dan Cotruta Operations Manager, London Innovation Centre. Tel: 0203 006 7278 Mob: 0779 163 4020 London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP (T) 0845 262 8545 (F) 020 8481 0460 (e) info@linnoc.net (w) www.linnoc.net London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited. Registered in England under no. 4557707.