Time Zones
I never much appreciated the complexities of dealing with time zones until a previous episode with DD-WRT puking. During that calamity I used the WRT54GL “Little Router That Could” as an emergency replacement. That episode introduced me to some of the complexities of time zones.
I want to build my own gateway system to dispense with the breakage often introduced by DD-WRT. Until then I continue to use DD-WRT because the firmware does function despite unforeseen and unexpected bugs and quirks. A classic love-hate relationship.
The Little Router That Could was wildly popular in its day. I bought the router in 2006. Within a few days of purchasing the WRT54GL I flashed the system with DD-WRT. DD-WRT also was wildly popular in those days. The last time I updated the WRT54GL was with the “SP2” firmware. That firmware version now is about a dozen years old. Considering the unreliability of DD-WRT and the WRT54GL is the appointed house network emergency router, I am hesitant to tinker with the firmware.
There might be unpatched exploits with such firmware. Yet there are no open WAN ports on the WRT54GL. I am comfortable with this configuration.
Despite being an emergency backup and having less capable hardware, as much as practical I want the Little Router That Could to behave much the same as the Asus RT-AC66U router.
So I tinker.
I have some custom scripts on the routers. Each time I find myself using the Little Router That Could I notice anomalies with my scripts because of the older firmware and less capable hardware.
One such quirk is I have the Asus router configured to send a Wake-on-Lan (WoL) magic packet to boot the office computer. The office computer is the primary computer used in the house and is the house network file server. This WoL script works fine on the Asus.
The script failed on the WRT54GL. I soon learned why — the older firmware only uses and displays UTC for the system clock. The firmware in the Asus router displays local time and the script uses local time to determine when to send a WoL magic packet.
The older firmware has no way to know the time zone and cannot directly use local times. I found an old forum discussion about the problem. Newer firmware would resolve the deficiency and better support local times, but I have been bitten too many times by DD-WRT. The WRT54GL is an emergency device and has to “just work.” The device will remain fixed on the “SP2” firmware. Let sleeping dogs lie.
Living in North America means the difference between local and UTC times is several hours. The script calculations are offset by this difference, which is further offset by the silliness of daylight saving time. The script failed to perform as intended on the WRT54GL because the UTC time did not match the expected human local time.
One solution would be to configure both router clocks to display UTC and pretend the time display is “local.” This solution could succeed and the WoL script and firmware would not “know” the distinction. I decided against that option. Phrases such as “dirty hack” came to mind.
In hindsight I am reasonably certain when I was regularly using the WRT54GL I did not realize the clock was only using UTC. Back then I also was not running any fancy scripts.
In those days the house network was limited and more simple. These days I wanted a technically correct solution. Dirty hacks often succeed but tend to open doors to unforeseen problems. The DD-WRT version in the Asus router has the ability to use local times. I did not want or need to force that router to fake the times.
I did not want to venture down this road because all computers in the house network use the same local time presumption to power down at night. The cron and at scheduling utilities use a local time interface. The office computer uses that presumption to self awaken to perform various tasks. All of these times and related scripts presumed local times by the user.
I let the problem fester in my head for some days.
To determine when to send that WoL packet the script sources a file containing variables. On all computers in the house network that information is stored in /etc/default/nightly. On the routers this variable file is stored in /jffs/etc/.
In the house network that variable file is used by several shell scripts. The file is sourced in cron and at jobs to automatically perform computer tasks. The two primary variables are NIGHT_BEGINS and NIGHT_ENDS. For easier calculations the times are stored in 24-hour format. The WoL script sends a magic packet only during “day” hours defined by those two variables.
I created a new variable TIME_ZONE.
The office computer is the house network file server and is the repository for all common system configuration files. I modified the rc.local boot script to check this new variable. The variable content is compared to the output of date +%Z. Because all house computers automatically adjust the time during both annual daylight saving transitions, on boot this check automatically updates the TIME_ZONE variable.
When the office computer runs cron.daily scripts the variable file is synchronized to the router.
I modified the WoL script to use the TIME_ZONE variable to convert UTC times to “local” time. The script presumes local time zones rather than support the offset of all time zones. The script adjusts the “local” time only for a router stuck with UTC times by running $(date | grep UTC).
The Little Router That Could now could send a WoL magic packet during the correct time of day.
This is not a perfect solution. On both days of the annual daylight saving time transition, the WRT54GL router will not yet have a copy of the updated variable file. When first powered on the Little Router That Could would not send a WoL packet at the expected time. If that happened the office computer would need to be powered on manually for that day only. This hiccup only affects the WRT54GL, which is used only in emergencies. Unless DD-WRT again pukes explicitly during a time zone transition I am unlikely to experience this shortfall.
I could have done nothing. The WRT54GL is a temporary emergency replacement. Manually powering on the office computer is hardly the end of the world. Yet sometimes there is fun finding solutions to challenging problems.
I still need to build a gateway system and walk away from DD-WRT.
Posted: Category: Usability Tagged: General
Next: Deprecated Commands
Previous: Man Man