public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: ma.jiang@zte.com.cn, libc-alpha@sourceware.org
Subject: Re: [PATCH]   tzset did not catch changes to localtime  [BZ #21060 ]
Date: Thu, 02 Nov 2017 15:33:00 -0000	[thread overview]
Message-ID: <585c61e3-97c1-afcb-c363-cc44e7fef391@redhat.com> (raw)
In-Reply-To: <201711021703324026436@zte.com.cn>

On 11/02/2017 02:03 AM, ma.jiang@zte.com.cn wrote:
> Hi, If users modified the local timezone file (usually
> /etc/localtime) while keep the TZ environment variable untouched,
> tzset will not recalculate tzname. This is not right. Patch attached
> should fix this problem, is it OK for trunk?

Thank you for the patch! The idea you present is interesting, but it
makes tzset() expensive when run in a loop, and several interfaces
call tzset() unconditionally to update the timezone in the event the
API call is the first in the sequence. For example mktime must call
tzset, and previously this might have been fast, but now it re-reads
the file every time. I don't think this is an acceptable solution
to the problem, but without a microbenchmark we don't know. So one
way to make your point would be to contribute a microbenchmark for
tzset or mktime, and show that the performance difference is
negligible. The other alternative is to go a layer down and stat
/etc/localtime (if that file is going to be used), and therefore
provide a quick way to avoid reloading the file if it hasn't changed.
All of this also will need a test case, which may or may not be
possible e.g. test starts in one timezone, updates the file used
(via TZ to full path of timezone), and then calls tzset, and verifies
that timezone has changed.

Lastly, this patch is a non-trivial number of lines and the copyright
status of ZTE is not yet clear. I will continue the copyright
discussion off-list with you directly.

Thank you again for your contribution.

-- 
Cheers,
Carlos.

  reply	other threads:[~2017-11-02 15:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-02  9:03 ma.jiang
2017-11-02 15:33 ` Carlos O'Donell [this message]
2017-11-07 10:27   ` ma.jiang
2017-11-02 23:48 ` J William Piggott
2017-11-03  8:16   ` 答复: " ma.jiang
2018-12-17  9:40 ma.jiang
2018-12-17  9:40 ` [PATCH] " Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=585c61e3-97c1-afcb-c363-cc44e7fef391@redhat.com \
    --to=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=ma.jiang@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).