Dominique wrote:
> Bram Moolenaar <b...@moolenaar.net> wrote:
>
> > Tom Ryder wrote:
> >
> > > Hello Vim developers; attached is a suggested patch for correcting
> > > a problem I noticed with time zones and Vim's strftime() function since
> > > v8.1.1313, with an accompanying test.
> > >
> > > I was not sure how best to do this portably, but I hope that the patch
> > > description and the diff that corrects the problem on my Debian
> > > GNU/Linux system at least points you in the right direction for
> > > correcting the issue.
> >
> > [...]
> >
> > > The POSIX spec for localtime(3) and localtime_r(3) says:
> > >
> > > > The localtime() function converts the calendar time timep to
> > > > broken-down time representation, expressed relative to the user's
> > > > specified timezone. The function acts as if it called tzset(3) and
> > > > sets the external variables tzname with information about the current
> > > > timezone, timezone with the difference between Coordinated Universal
> > > > Time (UTC) and local standard time in seconds, and daylight to
> > > > a nonzero value if daylight savings time rules apply during some part
> > > > of the year. The return value points to a statically allocated struct
> > > > which might be overwritten by subsequent calls to any of the date and
> > > > time functions. The localtime_r() function does the same, but stores
> > > > the data in a user-supplied struct. It need not set tzname, timezone,
> > > > and daylight.
> > >
> > > The last sentence of the specification is most relevant here. Patch
> > > 8.1.1313 (tag v8.1.1313, commit 63d2555) replaces calls to localtime(3)
> > > with localtime_r(3) if available, but does not call tzset() before each
> > > invocation.
> >
> > I don't understand the sentence. "It need not set", what does that mean
> > exactly? That it's not needed to set to variables? That it maybe sets
> > them, maybe not?
> >
> > Anyway, who needs those variables anyway? The manpage just mentions
> > they are set, but not where or how they are used.
> >
> > I would guess that localtime() always sets the variables, while
> > localtime_r() is not guaranteed to do that. But it does NOT say that
> > calling tzset() before localtime_r() is required to get correct results.
> >
> > > On Debian GNU/Linux with GNU libc 2.24-11+deb9u4, this results in
> > > a timezone "sticking" after the first tzset() instance, meaning that
> > > changes to the TZ environment variable do not take effect in between
> > > invocations.
> > >
> > > As an example:
> > >
> > > :let $TZ = "UTC" | echo $TZ.' -> '.strftime("%c")
> > > UTC -> Wed 12 Jun 2019 04:10:29 UTC
> > > :let $TZ = "Pacific/Auckland" | echo $TZ.' -> '.strftime("%c")
> > > Pacific/Auckland -> Wed 12 Jun 2019 04:10:32 UTC
> > >
> > > Note that neither the hour nor the reported timezone changes in the
> > > stftime() output between invocations, even though the value of the TZ
> > > environment value itself does change as expected.
> > >
> > > This commit adds a call to tzset(3) before each call to localtime_r(3),
> > > and corrects the above misbehavior, including checks for the
> > > availability of both functions.
> >
> > How expensive is a call to tzset()? It looks like it may read the
> > timezone database, which means file I/O and thus quite expensive.
> > Perhaps tzset() should only be called once, or perhaps only when the $TZ
> > variable was changed? I actually don't see how $TZ can change while Vim
> > is running, would require starting Vim on a laptop, travelling to
> > another timezone, and continuing editing?
>
> The code tzset is here:
> https://github.com/eggert/tz/blob/master/localtime.c#L1396
>
> tzset() looks fast when TZ has not changed as from what I see,
> it then merely:
>
> * locks a mutex
> * calls getenv("TZ")
> * compares TZ value with a previous value
> * unlocks a mutex
That is one implementation. How about other systems?
I think we should stay on the safe side.
--
hundred-and-one symptoms of being an internet addict:
186. You overstay in the office so you can have more time surfing the net.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201906151406.x5FE6Hir012558%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
