[tz] 回复: 回复: zoneinfo generating issues

[Ian Abbott]

On 05/03/2021 20:29, Ian Abbott via tz wrote:
> On 05/03/2021 10:01, 汪蒙蒙（木之） via tz wrote:
>> but the problem still exists. I have put my analysis tool and its 
>> codein the docker image, "damon0708/zic:v0.3". The tool is writen in 
>> golang and easy to be used.
>> # ./main -h
>>    -l string
>>      local time need to transfer (default "2022-11-01 00:00:00")
>>    -path string
>>      used to parse timezone (default "/usr/share/zoneinfo")
>>    -tz string
>>      the timezone you want transfer (default "America/Adak")
>>
>> After making the zoneinfo in path "/app/zoneinfo",
>>
>> # ./main -l "2022-11-01 00:00:00" -path "/usr/share/zoneinfo" -tz 
>> "America/Adak"
>> UTC: 2022-11-01 09:00:00 +0000 UTC
>> # ./main -l "2022-11-01 00:00:00" -path "/app/zoneinfo" -tz 
>> "America/Adak"
>> UTC: 2022-11-01 10:00:00 +0000 UTC
>>
>> The tool uses the golang standard library "time", which can be 
>>   specified the zoneinfo path by the env "ZONEINFO". So I don't think 
>> it is the problem of the tool.
> 
> The problem seems to be related to the use of leapseconds.
> 
> # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz 
> America/Adak
> UTC: 2022-11-01 09:00:00 +0000 UTC
> # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo/right -tz 
> America/Adak
> UTC: 2022-11-01 10:00:00 +0000 UTC

I ran that test in the docker image, but I cannot reproduce it on my 
Debian testing systems.  Both commands produce a UTC time of 10:00:00 on 
my Debian systems.

It could be a different golang environment, or it could be due to the 
Alpine Linux docker image using musl libc rather than glibc.

-- 
-=( Ian Abbott <abbotti at mev.co.uk> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268.  Registered address:    )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-