Posix Lua VM and os timezone update bug

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Posix Lua VM and os timezone update bug

Nenad Kljajić
scenario:
1. start Lua VM compiled with posix flag running process and use os.date()
2. change system wide timezone settings
3. use again os.date() from the earlier started process

expected result:
changes in system wide timezone settings should reflect return value for os.date()

actual result:
os.date() return value are based on the timezone settings when the Lua VM process was created

proposed fix:

--- lua-5.2.3/src/loslib.c 2013-04-12 20:48:47.000000000 +0200
+++ pa/lua-5.2.3/src/loslib.c 2014-10-31 02:05:13.345167821 +0100
@@ -200,8 +200,12 @@
     stm = l_gmtime(&t, &tmr);
     s++;  /* skip `!' */
   }
-  else
+  else {
+#if defined(LUA_USE_GMTIME_R)
+    tzset();
+#endif
     stm = l_localtime(&t, &tmr);
+  }
   if (stm == NULL)  /* invalid date? */
     lua_pushnil(L);
   else if (strcmp(s, "*t") == 0) {


Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Luiz Henrique de Figueiredo
This is not a Lua bug: the same thing will happen in a plain C program.
It does not sound polite for a library function in Lua to call tzset:
that should be the prerogatives of the host program.

Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Daurnimator
In reply to this post by Nenad Kljajić
On 30 October 2014 21:06, Nenad Kljajić <[hidden email]> wrote:
scenario:
1. start Lua VM compiled with posix flag running process and use os.date()
2. change system wide timezone settings
3. use again os.date() from the earlier started process

expected result:
changes in system wide timezone settings should reflect return value for os.date()

actual result:
os.date() return value are based on the timezone settings when the Lua VM process was created



On newer systems (that use systemd), you should be able to respond to changes via subscribing to timedated over dbus.
Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Nenad Kljajić
In reply to this post by Luiz Henrique de Figueiredo
If you carefully read the following discussion: http://stackoverflow.com/questions/19170721/real-time-awareness-of-timezone-change-in-localtime-vs-localtime-r , you will notice that my bug report is *only POSIX* related. This pary of Lua code is the problem:

/*
** By default, Lua uses gmtime/localtime, except when POSIX is available,
** where it uses gmtime_r/localtime_r
*/
#if defined(LUA_USE_GMTIME_R)

#define l_gmtime(t,r) gmtime_r(t,r)
#define l_localtime(t,r) localtime_r(t,r)

#elif !defined(l_gmtime)

#define l_gmtime(t,r) ((void)r, gmtime(t))
#define l_localtime(t,r)   ((void)r, localtime(t))

#endif



2014-10-31 2:15 GMT+01:00 Luiz Henrique de Figueiredo <[hidden email]>:
This is not a Lua bug: the same thing will happen in a plain C program.
It does not sound polite for a library function in Lua to call tzset:
that should be the prerogatives of the host program.


Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Roberto Ierusalimschy
> If you carefully read the following discussion:
> http://stackoverflow.com/questions/19170721/real-time-awareness-of-timezone-change-in-localtime-vs-localtime-r
> [...]

As far as the official documentation goes, 'tzset' is not garanteed to
be reentrant. Therefore, automatically calling 'tzset' everytime you
are going to call 'localtime_t' seems to defeat the whole point of
using 'localtime_t' (instead of 'localtime').

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Nenad Kljajić
As 'localtime_r' is preferred, because it is thread safe, then if some application needs awareness of timezone changes, it should use external library like http://luaposix.github.io/luaposix/docs/modules/posix.html#localtime

Thank you for clarifying that.
Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Roberto Ierusalimschy
> As 'localtime_r' is preferred, because it is thread safe, then if some
> application needs awareness of timezone changes, it should use external
> library like
> http://luaposix.github.io/luaposix/docs/modules/posix.html#localtime
>
> Thank you for clarifying that.

If you want, you can configure your Lua version to call tzset by adding
the following definitions at the end of luaconf.h (or in your makefile):

  #define l_gmtime(t,r) gmtime_r(t,r)
  #define l_localtime(t,r) (tzset(), localtime_r(t,r))

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Gé Weijers
The downside of this approach is that you end up processing a zoneinfo
file each time you just intend to call localtime/localtime_r.
Depending on the time zone that can take a substantial amount of time.
The zoneinfo files for Cairo, Chile and Jerusalem are over 8K on my
system.

To use tzset and localtime_r correctly in a multi-threaded environment
it is probably necessary to use a read/write lock or similar to make
sure no localtime_r call is in progress while tzset is parsing the
zoneinfo file.



On Mon, Nov 3, 2014 at 12:13 PM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> As 'localtime_r' is preferred, because it is thread safe, then if some
>> application needs awareness of timezone changes, it should use external
>> library like
>> http://luaposix.github.io/luaposix/docs/modules/posix.html#localtime
>>
>> Thank you for clarifying that.
>
> If you want, you can configure your Lua version to call tzset by adding
> the following definitions at the end of luaconf.h (or in your makefile):
>
>   #define l_gmtime(t,r)         gmtime_r(t,r)
>   #define l_localtime(t,r)      (tzset(), localtime_r(t,r))
>
> -- Roberto
>



--


Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Daurnimator
On 3 November 2014 16:28, Gé Weijers <[hidden email]> wrote:
The downside of this approach is that you end up processing a zoneinfo
file each time you just intend to call localtime/localtime_r.
Depending on the time zone that can take a substantial amount of time.
The zoneinfo files for Cairo, Chile and Jerusalem are over 8K on my
system.

To use tzset and localtime_r correctly in a multi-threaded environment
it is probably necessary to use a read/write lock or similar to make
sure no localtime_r call is in progress while tzset is parsing the
zoneinfo file.


This is why things like 'timedated' exist.
If you're on a system with it available, you can subscribe to the 'PropertyChanged' signal on the 'timezone' property, and react to it.
Reply | Threaded
Open this post in threaded view
|

Re: Posix Lua VM and os timezone update bug

Gé Weijers
Systemd about as OS dependent as it gets, definitely off-limits in a
language implementation that's trying to run on more than recent Linux
builds.
In my experience, once a program needs to do things like switching
timezones on the fly you're likely to have to handle multiple time
zones, and then localtime_r is inadequate anyway.


On Mon, Nov 3, 2014 at 1:39 PM, Daurnimator <[hidden email]> wrote:

> On 3 November 2014 16:28, Gé Weijers <[hidden email]> wrote:
>>
>> The downside of this approach is that you end up processing a zoneinfo
>> file each time you just intend to call localtime/localtime_r.
>> Depending on the time zone that can take a substantial amount of time.
>> The zoneinfo files for Cairo, Chile and Jerusalem are over 8K on my
>> system.
>>
>> To use tzset and localtime_r correctly in a multi-threaded environment
>> it is probably necessary to use a read/write lock or similar to make
>> sure no localtime_r call is in progress while tzset is parsing the
>> zoneinfo file.
>>
>> Gé
>
>
> This is why things like 'timedated' exist.
> If you're on a system with it available, you can subscribe to the
> 'PropertyChanged' signal on the 'timezone' property, and react to it.
> http://www.freedesktop.org/wiki/Software/systemd/timedated/



--