Daylight Savings Time
[posted 2000/06/19]
On a different matter, a couple of months ago, the =set_lineage() macro began misbehaving-- scripts were falsely reporting log file entries to be out-of-date. After a while, I traced the "misbehavior" to the switch to Daylight Savings Time. I then made the following changes.
In defines.cfg, I added:
dst TRUE // TRUE if Daylight Savings Time now applies, // FALSE otherwise (note: we need to automate the // toggling of this somehow)
In macros.cfg, I added this new macro definition:
nowdst // the current time, #now(), adjusted for Daylight Savings Time #now() #ifdef dst + 3600 #endifdef
Also in macros.cfg, I modified =set_lineage(), substituting =nowdst for #now():
set_lineage(L) // for the given line (L), determine its age, in seconds, // according to its date/time stamp (if any) // for syslog and many other log files; look for a date/time // stamp like "Feb 2 10:25:20" at the beginning of a line if #parse("(L)", "^(=months)[[:space:]]+([[:digit:]]+)[[:space:]]+ ([[:digit:]]+):([[:digit:]]+):([[:digit:]]+)") == 5 set #lineage = =nowdst - (#datevalue(#year(), #monthnumber($1), #val($2)) + #timevalue(#val($3), #val($4), #val($5))) [the remainder omitted for brevity]
With these adjustments, and after a reinstall of all affected scripts on all systems, =set_lineage() was "behaving" again.
You can see in the dst comments above that, ideally, we want to automate the toggling of dst between TRUE and FALSE as we slip into and out of Daylight Savings Time. I don't have a good technique for that yet.
I might eventually set a =remind(..., "TOGGLE DST IN DEFINES.CFG") in an Admin script to handle this.
Also, I don't want to attempt a #nowdst() function, because I don't want to deal with the complexities of Daylight Savings Time as it may be implemented in various countries across the globe. (There are no doubt library routines to handle this, but especially given the potential differences among Unixes, I'd rather not.)
There's no escaping the fact: Our environment is complex, and some of the PIKT solutions tend towards complexity also. I assert that you can't capture every last detail about your domain in a simple set of configuration rules. Some situations are messy, and some situations require non-trivial scripting. In the coming months, we will attempt to put together a PIKT "standard library" of scripts, macros, objects sets, and so on. But the power of PIKT is the power to bend and shape according to your needs and to get things "just right".
For more examples, see Developer's Notes.