Comments (3)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 localhost commented Permalink

Is there any good reason for having specific DST support rather than simply relying on the $TZ environment variable being set appropriately by the administrator? It certainly doesn't do those of us in Europe a lot of good as we change on different days, and the time can vary, too.

2 localhost commented Permalink

To answer the comment by SCG:<div>&nbsp;</div> The TZ environment variable is in fact the means of controlling the tiemzone settings, whether the APARs are installed or not.<div>&nbsp;</div> Consider three scenarios:1) The TZ variable is set and indicates no DST is observed. In this case, the APAR has no impact, because no timechange will occur in the first place.<div>&nbsp;</div> 2) The TZ variable is set and specifies DST is in effect, and it specifies the specific start and stop rules for the desired location. In this case, again, the APAR has no impact. The TZ variable DST rule is the final word.<div>&nbsp;</div> 3) The TZ variable is set and says DST is in use, but there is no TZ indication for when to start and stop observation of DST. This is the case where the default rule is used, which is where the APAR comes into play starting in 2007.The default through 2006, if set explicitly, would look like: M4.1.0,M10.5.0 (M4.1.0 = Month 4 [apr], week 1, day 0 [sun])The default starting in 2007 is like manually setting the rule to this: M3.2.0,M11.1.0<div>&nbsp;</div> In other words, for locations that set their full TZ variable including a DST rule, the APAR has no impact and is not relevant.

3 localhost commented Permalink

Thanks to David Clissold for his informative commentary, and for including the example syntax for the DST rule string.