Microsoft’s briefly bricked Zunes illustrates that date and time math is complicated, and is best handled by a module or library, instead of one-off untested error-prone code. Then, the standard library or module should have regression tests written for it, including one to exercise leap years. The many exceptions and edge cases of date and time math demand this level of care and attention.
Leap seconds may also cause problems, notably in log scanning, where the regular expression :[0-5][0-9] is used to match the seconds. This fails for the leap second of :60. Avoiding this bug is best done by generalizing the regular expression, and either ignoring the entire time stamp, or passing the entire time stamp off to a proper date processing module.
For example, if anchoring a regular expression to avoid false alarms, generalize the time stamp, as the seconds or other portions of it will not be used elsewhere. For example, the time can be skipped over via a simple “eight characters worth of digits and colon”:
# Check for fatal logs # Example: Jan 18 12:59:42 host fooproc[123]: FATAL: … watchfor /(?i)^\S+\s+\d+\s+[\d:]{8}\s+\S+\s+\S+\[\d+\]:\s+FATAL:/ …
Simply checking for FATAL anywhere in the log line will yield needless false alarms, especially for arbitrary data in logs, such as book titles or random base64-encoded data structures or even entire HTML pages developers felt the need to dump into the (production!) logs. Hence the need to anchor the regular expression, which both speeds the match and adds context to prevent false alarms—at the risk of missing alarms, should the log format change without the regular expressions also being updated.
Technorati Tags: coding