Date: Sat, 20 Jan 2024 21:32:39 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 276281] lang/python39 fails to include tzset in time module Message-ID: <bug-276281-21822-6DF6d4J5Br@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-276281-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-276281-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276281 --- Comment #5 from Ken McDonell <kenj@kenj.id.au> --- I'm no bugzilla wizard, nor a FreeBSD bug workflow expert, so please do what you need to ... the root cause appears to be in libc's localtime(). But please note the Python problem is a build-time issue, not a run time is= sue, so once localtime() is fixed, Python will need to be re-built and re-releas= ed. The issue has nothing to do with the system's timezone, the reproducer snip= pet I included originally explicitly sets TZ in the environment, calls tzset() = and localtime() returns the wrong result. I've attached a small C program that reproduces the problem, and here is my output: kenj@vm06:~$ cc groundhog.c=20 kenj@vm06:~$ a.out OK I am: FreeBSD 13.2-RELEASE-p4 GENERIC 13.2-RELEASE-p4 kenj@vm10:~$ cc groundhog.c=20 kenj@vm10:~$ a.out Botch hour=3D10 not 11 Botch isdst=3D0 not 1 I am: FreeBSD 14.0-RELEASE-p3 #0: Mon Dec 11 04:54:25 UTC 2023=20=20=20=20 root@amd64-builder.daemonology.net:/usr/obj/usr/src/i386.i386/sys/GENERIC 14.0-RELEASE-p3 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-276281-21822-6DF6d4J5Br>