zdump

[Dan Cotruta]

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 at 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 at 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 at linnoc.net]
> Sent: Monday, August 11, 2008 8:30
> To: tz at 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 at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20080811/8af12a12/attachment-0001.html