-1

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=XXXST5
  • tzoffset=5, dst=true: TZ=XXXST5XXXDT,M11.1.1/0,M3.1.1/0
  • tzoffset=2, dst=true: TZ=XXXST2XXXDT,M11.1.1/0,M3.1.1/0

DRAWBACKS 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)
Luciano
  • 1,159
  • Why wouldn't you simply translate the Olson string to a POSIX format using whatever the tzdb would have been at the time the data was recorded, look the result up in a map, and spawn/fork an instance of the service if you don't already have a running one listed in that map for that POSIX string? – Michael Mol May 11 '17 at 19:22
  • Interesting. Could you elaborate more about that ? – Luciano May 11 '17 at 21:03
  • You presumably have the Olson time for the data set. You can generate a POSIX TZ string from the Olson string by looking up what it would be. You take the resulting string and spawn a process with that TZ. Except when the process finishes with the data, you don't kill it, but keep it around, feeding it more data when you hit another dataset with that POSIX-form TZ. – Michael Mol May 11 '17 at 23:00

1 Answers1

1

This is in general impossible. An absolute offset (at some given point in time) plus a DST flag is not enough information to specify a particular time zone. You don't have any information about when the DST begins and ends. You can't even know for sure whether DST is currently in force.

If you are only interested in knowing the UTC offset at a given point in time, well, you already have that as you are given it.

If you need to compute the UTC offset at arbitrary other points in time, you need more information — ideally the actual (Olson) name of the timezone.

Celada
  • 44,132
  • You are sure, but look that the TZ var has assumed to have a default time zone configuration plus dst settings in POSIX format (which is the same for all others time zones supported). So, the service needs only to change de TZ env var (lets say setenv() or tzset()) before its processing. A test has confirmed that works, but has some drawbacks, very bad drawbacks.. – Luciano May 11 '17 at 21:00
  • Calling setenv() and tzset() has problems of its own: it's process-global (will interact badly with threads) and slow (will interact badly with large numbers of requests serviced). But ignoring that, my point does stand. Say for example the current date is 2017-07-01 and the current offset is -0500 and the current timezone has DST. You cannot know whether DST is currently active active, because it depends on the start and stop dates for DST in the local timezone which you don't know and on the local hemisphere (is it summer or winter?) which you also don't know. – Celada May 12 '17 at 18:46
  • In POSIX format we know if DST is configured. When TZ=XXXST5 there isn't DST configured, but when TZ=XXXST5XXXDT or TZ=XXXST5XXXDT,M3.1.1/2,M11.1.1.1/2 there's DST configured, so if you cut TZ to have just the time zone info XXXST5 the DST isn't enabled for that time zone. Our tests confirmed that. But performance can be a point of attention, although multi-threading not (this service is synchronous and mono-threaded) - the service consumes just one stream of data, per process instance. – Luciano May 12 '17 at 18:59