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.