[tz] proposed changes for Win32 and a improved mktime() algorithm

Kees Dekker Kees.Dekker at infor.com
Mon May 29 07:15:49 UTC 2017


>The point (about which I was not all that clear really) is that using
>putenv is the wrong way (normally) to deal with time zones which the
>application wants to use (and to use a putenv solution, it has to know
>the zone - get it from somewhere.)

>The better solution (which already exists) is to use parallel functions
>which are told which zone to use explicitly.  That way you can operate in
>as many different zones as you like (well, up to the number that exist)
>in parallel, with no overhead at all (except the ram they use.)

Please forgive my innocence. It would be great if you provide function names.
I assume you are pointing to function names in localtime.c?
Do you mean the _rz functions? But then NETBSD_INSPIRED need to be defined 
(no problem, but may result in another porting issues for me on MS-Windows).

...

>Because, if it were useful at all, that would defeat the point.   The whole
>idea of yearistype was to be able to easily express relationships between
>years, and labels, that were unknown when the code was written.   Anyone
>can add a line (or several) to a script to work out which years are
>"the year of the dog", but the code writers cannot, as they have no idea
>that this particular information is considered (by someone) to be useful.

I saw that Paul has started to make the -y option obsolete, thanks. This will
solve another non-portable thing for MS-Windows.

...

>The versions of the functions with the _z suffix (including _rz) which
>take an explicit zone (the result of tzalloc(zone_name) as a parameter
>should make things run much faster (and more reliably, especially if your
>applications are multi-threaded) than anything using putenv.

I will check and try to use the TZ code with as less modifications as possible.

>You don't need that with the _z functions, they are *all* cached (all the
>ones that you are using anyway - and the application can decide whether
>it is better to retain a loaded zone, or save space and discard it, and
>then load it again later.)

Will check.

Kees


More information about the tz mailing list