<div dir="ltr">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.<br>
<br>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?<br><br>Example:<br><br>Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S<br>
Rule EUAsia 1979 1995 - Sep lastSun 1:00u 0 -<br>Rule EUAsia 1996 max - Oct lastSun 1:00u 0 -<br>----------------------From this point on there's no tab between the word Rule and the zone name-----------------<br>
Rule E-EurAsia 1981 max - Mar lastSun 0:00 1:00 S<br>Rule E-EurAsia 1979 1995 - Sep lastSun 0:00 0 -<br>Rule E-EurAsia 1996 max - Oct lastSun 0:00 0 -<br>
Rule RussiaAsia 1981 1984 - Apr 1 0:00 1:00 S<br>Rule RussiaAsia 1981 1983 - Oct 1 0:00 0 -<br>Rule RussiaAsia 1984 1991 - Sep lastSun 2:00s 0 -<br>
Rule RussiaAsia 1985 1991 - Mar lastSun 2:00s 1:00 S<br>Rule RussiaAsia 1992 only - Mar lastSat 23:00 1:00 S<br>Rule RussiaAsia 1992 only - Sep lastSat 23:00 0 -<br>
Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S<br>Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 -<br>Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 -<br>
<br><br>This occurs in a number of places and it makes writing a search algorithm a lot harder - I wonder if anyone has any input.<br><br><br>Dan<br><br><div class="gmail_quote">On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <span dir="ltr"><<a href="mailto:dancotruta@linnoc.net">dancotruta@linnoc.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">Oh - and forgive the confusion above between Mauritius and Madagascar.<div><div>
</div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <span dir="ltr"><<a href="mailto:dancotruta@linnoc.net" target="_blank">dancotruta@linnoc.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">Sorry, I should have also added this failure case:<br><br>[dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2009 Pacific/Guam<br>
Pacific/Guam -9223372036854775808 = NULL<br>Pacific/Guam -9223372036854689408 = NULL<br>
Pacific/Guam Tue Dec 31 14:20:59 1844 UTC = Mon Dec 30 23:59:59 1844 ChST isdst=0 gmtoff=-51660<br>Pacific/Guam Tue Dec 31 14:21:00 1844 UTC = Wed Jan 1 00:00:00 1845 ChST isdst=0 gmtoff=34740<br>Pacific/Guam Mon Dec 31 14:20:59 1900 UTC = Mon Dec 31 23:59:59 1900 ChST isdst=0 gmtoff=34740<br>
Pacific/Guam Mon Dec 31 14:21:00 1900 UTC = Tue Jan 1 00:21:00 1901 ChST isdst=0 gmtoff=36000<br>Pacific/Guam 9223372036854689407 = NULL<br>Pacific/Guam 9223372036854775807 = NULL<br><br>Any ideas on how the t_time / int problem relates to this?<div>
<div></div><div><br>
<br><br><div class="gmail_quote">On Mon, Aug 11, 2008 at 4:57 PM, Dan Cotruta <span dir="ltr"><<a href="mailto:dancotruta@linnoc.net" target="_blank">dancotruta@linnoc.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">Dear Olson,<br><br>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?<br>
<br>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.<br>int is the standard builtin integer type, which for reasons that evade me is still defined as 32 bits long.<br>
<br>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.<br><br>I hope that's right so far...<br>
<br>
So then:<br><br>Why does Madagascar fail?<br>[dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2008 Mauritius<br>Mauritius -9223372036854775808 = NULL<br>Mauritius -9223372036854689408 = NULL<br>Mauritius 9223372036854689407 = NULL<br>
Mauritius 9223372036854775807 = NULL<br><br>Here, the limit should be 2008 - therefore the 32 bit limit should not be a problem. Am I missing something?<br><br>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?<br>
<br>If so, I'd appreciate some help decrypting the logic of the tzdata files.<br><br>Thanks again for your swift reply,<br><font color="#888888"><br>Dan</font><div><div></div><div><br><span><span></span></span><br>
<br><div class="gmail_quote">
On Mon, Aug 11, 2008 at 2:07 PM, Olson, Arthur David (NIH/NCI) [E] <span dir="ltr"><<a href="mailto:olsona@dc37a.nci.nih.gov" target="_blank">olsona@dc37a.nci.nih.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
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.<br>
<br>
From: Dan Cotruta [mailto:<a href="mailto:dancotruta@linnoc.net" target="_blank">dancotruta@linnoc.net</a>]<br>
Sent: Monday, August 11, 2008 8:30<br>
To: <a href="mailto:tz@lecserver.nci.nih.gov" target="_blank">tz@lecserver.nci.nih.gov</a><br>
Subject: zdump<br>
<div><div></div><div><br>
Someone, please enlighten me - what do the numerical numbers in the output of zdump stand for?<br>
<br>
What I mean is, for this output:<br>
<br>
[dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2008,2009 America/Los_Angeles<br>
America/Los_Angeles -9223372036854775808 = NULL <------ What does this line signify?<br>
America/Los_Angeles -9223372036854689408 = NULL <------ What does this line signify?<br>
America/Los_Angeles Sun Mar 9 09:59:59 2008 UTC = Sun Mar 9 01:59:59 2008 PST isdst=0 gmtoff=-28800<br>
America/Los_Angeles Sun Mar 9 10:00:00 2008 UTC = Sun Mar 9 03:00:00 2008 PDT isdst=1 gmtoff=-25200<br>
America/Los_Angeles Sun Nov 2 08:59:59 2008 UTC = Sun Nov 2 01:59:59 2008 PDT isdst=1 gmtoff=-25200<br>
America/Los_Angeles Sun Nov 2 09:00:00 2008 UTC = Sun Nov 2 01:00:00 2008 PST isdst=0 gmtoff=-28800<br>
America/Los_Angeles 9223372036854689407 = NULL <------ What does this line signify?<br>
America/Los_Angeles 9223372036854775807 = NULL <------ What does this line signify?<br>
<br>
The number is far too large to be a standard timestamp, even in milliseconds... so what is it?<br>
<br>
Many thanks,<br>
--<br>
Dan Cotruta<br>
Operations Manager, London Innovation Centre.<br>
<br>
Tel: 0203 006 7278<br>
Mob: 0779 163 4020<br>
<br>
London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP<br>
(T) 0845 262 8545 (F) 020 8481 0460 (e) <a href="mailto:info@linnoc.net" target="_blank">info@linnoc.net</a> (w) <a href="http://www.linnoc.net" target="_blank">www.linnoc.net</a><br>
London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited.<br>
Registered in England under no. 4557707.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dan Cotruta<br>Operations Manager, London Innovation Centre.<br><br>Tel: 0203 006 7278<br>Mob: 0779 163 4020<br><br>London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP<br>
(T) 0845 262 8545 (F) 020 8481 0460 (e) <a href="mailto:info@linnoc.net" target="_blank">info@linnoc.net</a> (w) <a href="http://www.linnoc.net" target="_blank">www.linnoc.net</a><br>London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited.<br>
Registered in England under no. 4557707.<br>
</div></div></div>
</blockquote></div><br><br clear="all"><br></div></div>-- <br><div>Dan Cotruta<br>Operations Manager, London Innovation Centre.<br><br>Tel: 0203 006 7278<br>Mob: 0779 163 4020<br><br>London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP<br>
(T) 0845 262 8545 (F) 020 8481 0460 (e) <a href="mailto:info@linnoc.net" target="_blank">info@linnoc.net</a> (w) <a href="http://www.linnoc.net" target="_blank">www.linnoc.net</a><br>London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited.<br>
Registered in England under no. 4557707.<br>
</div></div>
</blockquote></div><br><br clear="all"><br></div></div>-- <br><div class="Ih2E3d">Dan Cotruta<br>Operations Manager, London Innovation Centre.<br><br>Tel: 0203 006 7278<br>Mob: 0779 163 4020<br><br>London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP<br>
(T) 0845 262 8545 (F) 020 8481 0460 (e) <a href="mailto:info@linnoc.net" target="_blank">info@linnoc.net</a> (w) <a href="http://www.linnoc.net" target="_blank">www.linnoc.net</a><br>London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited.<br>
Registered in England under no. 4557707.<br>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Dan Cotruta<br>Operations Manager, London Innovation Centre.<br><br>Tel: 0203 006 7278<br>Mob: 0779 163 4020<br><br>London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP<br>
(T) 0845 262 8545 (F) 020 8481 0460 (e) <a href="mailto:info@linnoc.net">info@linnoc.net</a> (w) <a href="http://www.linnoc.net">www.linnoc.net</a><br>London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited.<br>
Registered in England under no. 4557707.<br>
</div>