zdump
Dan Cotruta
dancotruta at linnoc.net
Tue Aug 12 12:22:21 UTC 2008
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.
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?
Example:
Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S
Rule EUAsia 1979 1995 - Sep lastSun 1:00u 0 -
Rule EUAsia 1996 max - Oct lastSun 1:00u 0 -
----------------------From this point on there's no tab between the word
Rule and the zone name-----------------
Rule E-EurAsia 1981 max - Mar lastSun 0:00 1:00 S
Rule E-EurAsia 1979 1995 - Sep lastSun 0:00 0 -
Rule E-EurAsia 1996 max - Oct lastSun 0:00 0 -
Rule RussiaAsia 1981 1984 - Apr 1 0:00 1:00 S
Rule RussiaAsia 1981 1983 - Oct 1 0:00 0 -
Rule RussiaAsia 1984 1991 - Sep lastSun 2:00s 0 -
Rule RussiaAsia 1985 1991 - Mar lastSun 2:00s 1:00
S
Rule RussiaAsia 1992 only - Mar lastSat 23:00 1:00 S
Rule RussiaAsia 1992 only - Sep lastSat 23:00 0 -
Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S
Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 -
Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 -
This occurs in a number of places and it makes writing a search algorithm a
lot harder - I wonder if anyone has any input.
Dan
On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <dancotruta at linnoc.net> wrote:
> Oh - and forgive the confusion above between Mauritius and Madagascar.
>
>
> On Mon, Aug 11, 2008 at 5:05 PM, Dan Cotruta <dancotruta at linnoc.net>wrote:
>
>> 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.
>>
>
>
>
> --
> 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/20080812/db02e967/attachment.htm>
More information about the tz
mailing list