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
Regards
Dominique
--
--
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/CAON-T_idQNHv1JNyHwV%3DX%2B2mXGenD8eh7MsQZBvV39Dn%3DbWfOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
