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

[Robert Elz]

    Date:        Wed, 24 May 2017 15:14:58 +0000
    From:        Kees Dekker <Kees.Dekker at infor.com>
    Message-ID:  <DM5PR02MB2809298A95EC38CE6C2FB046E9FE0 at DM5PR02MB2809.namprd02.prod.outlook.com>

  | 
  | >* I think Robert Elz covered the putenv issue fairly well: 
  | 
  | I've checked latest version, but do not understand how it is fixed.

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.)

  | Yes, but yearistype is always needed,

By what?   While I am sorry to see it go (in a way) as it provides
a flexibility that isn't available any other way, I cannot pretend that
it is actually useful anywhere currently, or any time in the recent
past - and for the older past, when it was needed, the zones have just
been explicitly coded with the results yearistype used to return.

What's more, these days there are so many unpredictable zone changes
every year, that there are constant new releases, which allows the
problems that yearistype used to solve to be handled by just adding more
rule lines - in the early days, it was naively assumed that the rules
would remain mostly constant for years, and all we needed to be able to
do was write down the rule (however complicated.)   That was a nice theory...

  | and if nobody changes the shell script, why not keep this code into C?

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.

  | Our own software heavily relies on switching time zones, so any
  | improvement is welcome.

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.

  |  We are considering to make a LRU cache, to cache the last 2 time
  | zonefiles loaded.

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.)

kre