A unique service instance needs to change the timezone according to the data being processed. So, it can change the TZ environment variable for each data before its processing, and so on.What is the best approach to change the TZ value to set time zone and DST (daylight saving time) dynamically ? Should it use Olson format or POSIX format ? Is possible to use Olson format and turn off DST ?Consider the characteristics below:TIME ZONE INFO's ORIGINS:The way it detects the time zone is from each information coming to be processed, which are:The absolute offset (from UTC)A flag to indicate if DST must be applied or not. Note that this flag doesn't say if the DST is in course, but just if the current DST settings are applicable.RESTRICTIONS:The DST flag assumes that there is just one DST configuration for all possible time zones expected. But although that service is supposed to run with a group of time zones with just one type of DST, some time zones have DST and others don't.The service doesn't know the DST settings to set TZ variable according to the POSIX format: Mm.w.d/time...POSSIBLE SOLUTION:The service can expects a TZ already configured with a default time zone and its DST (unique for all others time zones expected), in POSIX format, like as TZ=XXXST3XXXDT,M11.1.1/0,M3.1.1/0 For each time the service needs to change the time zone, it can change de original TZ variable just adjusting the offset and clearing or keeping the original DST settings as required by DST flag. Examples considering absolute offsets to this default time zone TZ=XXXST3XXXDT,M11.1.1/0,M3.1.1/0:tzoffset=5, dst=false TZ=XXXST5tzoffset=5, dst=true: TZ=XXXST5XXXDT,M11.1.1/0,M3.1.1/0tzoffset=2, dst=true: TZ=XXXST2XXXDT,M11.1.1/0,M3.1.1/0DRAWBACKS OF THIS SOLUTION:The service needs to run in a exclusive (separated) user with its own TZ variable - or any other way of launch process with its exclusive variables.This service cannot use the Olson time zone database: If the DST settings change every year, this system environment cannot use an integrated Olson database with a centralized update, being necessary to do an specific configuration (by hand or a customized update) for the service's TZ variable, every year in each server.The service will need a new configuration to know how to change the TZ offset, if it's absolute (from UTC) or if it's relative (from the time zone name)
Dynamic time zone in a running service
timezone