zdump

Dan Cotruta dancotruta at linnoc.net
Mon Aug 11 16:05:00 UTC 2008


Sorry, I should have also added this failure case:

[dcotruta at 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 at 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 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.
>



-- 
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/9ec1a646/attachment-0001.html 


More information about the tz mailing list