From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11412 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: detect timezone changes by monitoring /etc/localtime (like glibc) Date: Fri, 9 Jun 2017 08:15:02 -0400 Message-ID: <20170609121502.GO1627@brightrain.aerifal.cx> References: <488f8d57-555b-9328-f768-5779ea8aa8ec@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1497010518 1369 195.159.176.226 (9 Jun 2017 12:15:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Jun 2017 12:15:18 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11425-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 09 14:15:14 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dJIor-0008WV-JJ for gllmg-musl@m.gmane.org; Fri, 09 Jun 2017 14:15:13 +0200 Original-Received: (qmail 3160 invoked by uid 550); 9 Jun 2017 12:15:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3136 invoked from network); 9 Jun 2017 12:15:15 -0000 Content-Disposition: inline In-Reply-To: <488f8d57-555b-9328-f768-5779ea8aa8ec@gmail.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11412 Archived-At: On Fri, Jun 09, 2017 at 05:15:40PM +1000, Patrick Oppenlander wrote: > During some recent testing I came across a bug when adjusting timezones on an > embedded system by changing /etc/localtime. The cause ended up being a > behavioural difference between glibc and musl. This difference is intentional; I believe there are past discussions in the list archives. Aside from the glibc behavior giving abysmal performance (syscalls on every time operation), there's a more fundamental issue of usability of the results. A common important idiom with time functions is to perform several operations together in succession to get a result -- for example, obtain the current time as time_t, format it with localtime[_r], make some adjustment e.g. for a relative time, then call mktime to convert back to time_t. Such operations rely on the time zone being consistent for each suboperation, which is true as long as the application does not modify its own environment, but only assuming libc doesn't impose asynchronous changes on the timezone. In order for asynchronous timezone changes to be safe, the API would have to be such that you make one call to get the current timezone, then pass it as an argument to functions depending on the timezone, so that the application has control of which timezone is getting used in each call. Rich