<div dir="ltr">Oh - and forgive the confusion above between Mauritius and Madagascar.<br><br><div class="gmail_quote">On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <span dir="ltr">&lt;<a href="mailto:dancotruta@linnoc.net">dancotruta@linnoc.net</a>&gt;</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&nbsp; -9223372036854775808 = NULL<br>Pacific/Guam&nbsp; -9223372036854689408 = NULL<br>
Pacific/Guam&nbsp; Tue Dec 31 14:20:59 1844 UTC = Mon Dec 30 23:59:59 1844 ChST isdst=0 gmtoff=-51660<br>Pacific/Guam&nbsp; Tue Dec 31 14:21:00 1844 UTC = Wed Jan&nbsp; 1 00:00:00 1845 ChST isdst=0 gmtoff=34740<br>Pacific/Guam&nbsp; Mon Dec 31 14:20:59 1900 UTC = Mon Dec 31 23:59:59 1900 ChST isdst=0 gmtoff=34740<br>

Pacific/Guam&nbsp; Mon Dec 31 14:21:00 1900 UTC = Tue Jan&nbsp; 1 00:21:00 1901 ChST isdst=0 gmtoff=36000<br>Pacific/Guam&nbsp; 9223372036854689407 = NULL<br>Pacific/Guam&nbsp; 9223372036854775807 = NULL<br><br>Any ideas on how the t_time / int problem relates to this?<div>
<div></div><div class="Wj3C7c"><br>
<br><br><div class="gmail_quote">On Mon, Aug 11, 2008 at 4:57 PM, Dan Cotruta <span dir="ltr">&lt;<a href="mailto:dancotruta@linnoc.net" target="_blank">dancotruta@linnoc.net</a>&gt;</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&#39;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&#39;t work.<br><br>I hope that&#39;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&nbsp; -9223372036854775808 = NULL<br>Mauritius&nbsp; -9223372036854689408 = NULL<br>Mauritius&nbsp; 9223372036854689407 = NULL<br>


Mauritius&nbsp; 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&#39;t know anything about C programming - is this something that&#39;s likely to be fixed at some point soon? I&#39;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&#39;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">&lt;<a href="mailto:olsona@dc37a.nci.nih.gov" target="_blank">olsona@dc37a.nci.nih.gov</a>&gt;</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 &quot;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&#39;t be represented in 32-bit integers, so we can&#39;t correctly convert them to &quot;struct tm&quot;s that represent them--that&#39;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&nbsp; -9223372036854775808 = NULL &lt;------ What does this line signify?<br>
America/Los_Angeles&nbsp; -9223372036854689408 = NULL &lt;------ What does this line signify?<br>
America/Los_Angeles&nbsp; Sun Mar&nbsp; 9 09:59:59 2008 UTC = Sun Mar&nbsp; 9 01:59:59 2008 PST isdst=0 gmtoff=-28800<br>
America/Los_Angeles&nbsp; Sun Mar&nbsp; 9 10:00:00 2008 UTC = Sun Mar&nbsp; 9 03:00:00 2008 PDT isdst=1 gmtoff=-25200<br>
America/Los_Angeles&nbsp; Sun Nov&nbsp; 2 08:59:59 2008 UTC = Sun Nov&nbsp; 2 01:59:59 2008 PDT isdst=1 gmtoff=-25200<br>
America/Los_Angeles&nbsp; Sun Nov&nbsp; 2 09:00:00 2008 UTC = Sun Nov&nbsp; 2 01:00:00 2008 PST isdst=0 gmtoff=-28800<br>
America/Los_Angeles&nbsp; 9223372036854689407 = NULL &lt;------ What does this line signify?<br>
America/Los_Angeles&nbsp; 9223372036854775807 = NULL &lt;------ 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 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>