From nobody Sat Jan 28 17:38:24 2023 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P41rJ3PhDz3bR37 for ; Sat, 28 Jan 2023 17:38:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P41rJ1H4Bz4BvC for ; Sat, 28 Jan 2023 17:38:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674927504; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=WKavrnsVHuHdSV2yGlsmRDCxuMdLIONe5JLS+OHbmIc=; b=qknv+Vj9434DLmblFyuyKl6lB622spaLAMjOVpPoCPE3rgf9hTTz2n15PO/HzLmpHCmkk9 QsjvUklmcbWl8ooPAqcJ8jsu2btYXfcOxoeBlqpXval06oUU/EwUIE1v9By1ty1ZiHFK99 D5SvWMRZ+GxzxL/vNn9KOXsWYEZc4sne12+l4AFObVIIgFqTAIT58AsKY2VxniUMMWLZNG 2x887yv0fItcJfPOc/95wHYd14PD6FeMTl2L30ME17lq0jZbur3dEWrlbUBSSTYLJGNA/F JYDXvJF2VGoE+Zcn9NWedaHBWNiwUSzMBcgURyQ3svhvfDZRMa8DS6T1bskV3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674927504; a=rsa-sha256; cv=none; b=VBMc/KdR7EqnhGQMTRr+lLUJTAVi+xAsJvO/z3G2N6wI1JTrT2B6ci8afVGJMK7lfnGJJW GRjRMbWTnaNJ9z64WKZiSnqs9MCNl2OnERcL+6nZ2Q+pQRhyCU9uSlewOU+44E3j1WIYMe YLdzaEbcspAmxzPaGh/MvjEc+MyjGquoorfP7fCDGF1ptDxGOD8yjSpdI+N4M9Avdi/Mwg HbrEUpJqSNwcEYzJsJTDKuSiAgNBrEZU5qBxiTbvlTacAS3jbZuddP/xEk3ySOkhalqe9P OmAUWnjaFOUBub1UVThYDw0x9I7fXEDaf3IWMGsQqHq+QxPcCxuZY4P+bfGMxw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4P41rJ021Czx2r for ; Sat, 28 Jan 2023 17:38:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 30SHcNJm014754 for ; Sat, 28 Jan 2023 17:38:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30SHcNgp014753 for bugs@FreeBSD.org; Sat, 28 Jan 2023 17:38:23 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 269207] localtime.c fails to detect mobile device timezone change Date: Sat, 28 Jan 2023 17:38:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: fbsd@opal.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269207 Bug ID: 269207 Summary: localtime.c fails to detect mobile device timezone change Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: fbsd@opal.com Currently, localtime(3) determines the local timezone using either the TZ environment variable or the /etc/localtime file. Once it has obtained the = zone information, a flag is set, the zone information is cached and the informat= ion is re-used on subsequent calls to localtime() by the same program. In situations where long-running programs persist over mobile device moves = that span timezones, this behavior means that such programs will remain unaware = of any system timezone changes, resulting in events occurring at times not expected by the user. A real-world example is a laptop that executes cron(8) jobs at local times.= =20 The user suspends the laptop, travels to a new timezone, resumes the laptop= and updates the system timezone information using tzsetup(8) or other means.=20 Currently, cron(8) continues to execute jobs at times of the original timez= one. Desired behavior is that cron(8) starts to use the new timezone. Similarly for other long-running programs. Of course, long-running programs can be restarted after the timezone move.= =20 However, this may be undesirable, and restarting system programs such as cron(8) is not something that non-technical users may be aware of the need = for or even have sufficient privileges to do. In localtime.c, the flag (the variable "lcl_is_set") is used both by tzset_basic() and tzsetwall_basic(). In tzset_basic(), the flag is set to the length of the zoneinfo provided in= the TZ environment variable which, of course, will not change for the life of a long-running program. In tzsetwall_basic(), the flag is set to -1 when the zone information is re= ad from /etc/localtime. As described above, this file could be changed during= the life of a long-running program. The use of the lcl_is_set flag is therefore not suitable in this case. The attached patch removes the use of lcl_is_set from tzsetwall_basic() and replaces it with examination of the zone file's mtime in tzload() instead.= =20 Once the zone information has been loaded from the file, the file's name and mtime are stored. On subsequent calls, if these are unchanged, the cached = zone information is returned. Otherwise the file is re-read to obtain the new z= one information. When the TZ environment variable is unset, the existing code has the follow= ing calling sequence: localtime() =3D> tzset_basic() =3D> tzsetwall_basic() =3D> tzload() =3D= > tzparse() =3D> tzload() The first call to tzload() is to load the /etc/localtime zone file. The se= cond call to tzload() is to load the TZDEFRULES ("posixrules") zone file. The proposed patch is therefore aware of this and ignores that file when saving= the zone file's name and mtime. The patch also reorders tzload()'s _open() and _fstat() sequence to be a st= at() followed by _open() in order to avoid unnecessarily opening an unchanged fi= le and therefore triggering an unnecessary update of the inode's atime. Long-running programs started with a timezone specification in the TZ environment variable are unaffected by this patch. Even if /etc/localtime = is modified for a new timezone, such programs will continue to use the timezone specification in their TZ variable. This patch only affects programs for w= hich the TZ environment variable is not set and so /etc/localtime is used, or programs calling tzsetwall(3) directly. Also attached are a simple test program that calls localtime() repeatedly e= very 5 seconds and a Makefile to compile it and a patched localtime.c in a test directory. Run the program and then use tzsetup() or otherwise modify /etc/localtime to a different timezone while the program is running. --=20 You are receiving this mail because: You are the assignee for the bug.=