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@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. )=-