Date: Wed, 24 May 2017 15:14:58 +0000 From: Kees Dekker <Kees.Dekker@infor.com> Message-ID: <DM5PR02MB2809298A95EC38CE6C2FB046E9FE0@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