Time Zones & Daylight Saving
As we approach the moment when we adjust the clocks as we head into winter it seems appropriate to point out the date and time tools that JANOS has to offer.
bruce_dev /> date -v utc: 1509109889 Fri Oct 27 09:11:29 EDT 2017 Current Timezone is EST for the America/New_York area. Abbreviated EDT when Daylight Savings is in effect. DST begins at 02:00 on Sun on or after Mar 8th. DST ends at 02:00 on Sun on or after Nov 1st. When in effect DST sets clocks ahead by 1 hour. DST is currently in effect. bruce_dev />
The DATE -V command (V for verbose) offers a description of the current time status. Here we see that I have incorrectly referred to DST as “Daylight Savings Time” when in fact it is Daylight Saving Time. So, before posting this I’ll just update the JANOS code to correct that. My bad.
It is in fact Daylight Saving Time and it is designed to capture an hour of sunshine that we would otherwise be sleeping through in the morning. To do this we set our clocks ahead an hour in the Spring at a point when the Sun insists on rising an hour before we want to get up. Remember “Spring ahead. Fall back.” DST is in effect during the Summer. So instead of it being 6:00 AM when the Sun blares into the room and pisses you off by waking you early, it will be 7:00 AM and maybe you should get up. That hour of daylight then is shifted to the end of the day. So it could be almost 10:00 PM before you have to put that lawnmower away.
Seems like a reasonable thing to do. Well of course it causes all kinds of issues. Making matters worse not all timezones observe DST and some do but use a different set of rules. And although the rules haven’t been changed recently governments have been known to make adjustments. Sometimes DST usage is temporarily altered say for when we may be in an energy crisis. Then there are the cities or areas of a timezone that decide to not follow DST like the rest of their timezone. All of this makes it difficult for a device to cope.
By the way, I’ve fixed my problem. You’ll have to wait for JANOS v1.6.3 for this. Sorry.
bruce_dev /> date -v utc: 1509110646 Fri Oct 27 09:24:06 EDT 2017 Current Timezone is EST for the America/New_York area. Abbreviated EDT when Daylight Saving Time is in effect. DST begins at 02:00 on Sun on or after Mar 8th. DST ends at 02:00 on Sun on or after Nov 1st. When in effect DST sets clocks ahead by 1 hour. DST is currently in effect. bruce_dev />
Did you ever notice in windows that your file last modification times all change when you enable or disable DST?
Windows apparently applies timezone and current DST status to any time it displays. So if DST is in effect every time you see is adjusted even if DST wasn’t in effect at that point in the past. So if I save a file today (October) it will show the file was created today at such and such a hour. But if I check that file date next month (November) after we leave DST it would have been created an hour earlier that I did it. Perhaps even before I got into work. Show your boss that and tell him that all summer long you consistently made it in early and deserve a bonus.
Well the times will be off by an hour but trying to figure whether the times would be an hour earlier or later makes my head hurt.
JANOS has been programmed differently and perhaps correctly at least in my opinion. When a time is displayed JANOS uses DST if and only if DST was in effect at that past moment. So when DST is enabled or disabled the file times remain consistent. You know, if you have written a Windows application that uses a file’s last modification time to check if the file were changed, you’ll go nuts. Twice a year you would think that batches of files suddenly have changed. Yeah I know Windows keeps a changed flag that you can and maybe need to use. But in general the file times seem like a reasonable indication of a change (or different version). You should use UTC anyway.
Of course if you change the DST rules or your timezone for that matter the reported file times will naturally all change. It’s all no big deal anyway.
We’ve also somehow moved from selecting your timezone to specifying a nearby city for getting your clock to display correctly. Well there are hundreds of major cities and that database becomes quite large given there is a lot of repetition (there a multiple major cities in a single timezone). Meanwhile the JNIOR is just a small device and doesn’t have the luxury of wasting storage space that you’ve spent your hard earned dollars on.
In JANOS you select the timezone using its abbreviation and there is a short list of timezones included by default.
bruce_dev /> date -t Available timezones: IDLW (-1200) Date_Line WST (-1100) Pacific/Midway HST (-1000) Pacific/Honolulu AKST (-0900) America/Anchorage(1) PST (-0800) America/Los_Angeles(1) MST (-0700) America/Denver(1) CST (-0600) America/Chicago(1) IET (-0500) America/Indianapolis EST (-0500) America/New_York(1) PRT (-0400) America/Caracas CNT (-0330) America/St_Johns(1) AGT (-0300) Argentina/Buenos_Aires BET (-0300) Brazil/Brasilia MAT (-0200) Atlantic/Mid CAT (-0100) Atlantic/Cape_Verde GMT (+0000) Greenwich_Mean UTC (+0000) Universal_Coordinated WET (+0000) Western European(5) CET (+0100) Central European(4) EET (+0200) Eastern European(3) EAT (+0300) Asia/Riyadh MET (+0330) Iran/Tehran NET (+0400) Russia/Moscow AFT (+0430) Afghanistan/Kabul PLT (+0500) Russia/Ural_Mountains IST (+0530) India ALMT (+0600) Asia/Alma-Ata CIT (+0630) Burma VST (+0700) Mongolia/West AWST (+0800) Australia/Perth JST (+0900) Japan ACST (+0930) Australia/Adelaide(2) AEST (+1000) Australia/Sydney(2) LHT (+1030) Lord Howe Island SST (+1100) Russia/East NIT (+1130) Norfolk Island NST (+1200) Pacific/Fiji Note 1: DST begins at 02:00 on Sun on or after Mar 8th. Clocks move forward by 60 minutes. DST ends at 02:00 on Sun on or after Nov 1st. Note 2: DST begins at 02:00 on Sun on or after Oct 1st. Clocks move forward by 60 minutes. DST ends at 03:00 on Sun on or after Apr 1st. Note 3: DST begins at 03:00 on Sun on or before Mar 31st. Clocks move forward by 60 minutes. DST ends at 04:00 on Sun on or before Oct 31st. Note 4: DST begins at 02:00 on Sun on or before Mar 31st. Clocks move forward by 60 minutes. DST ends at 03:00 on Sun on or before Oct 31st. Note 5: DST begins at 01:00 on Sun on or before Mar 31st. Clocks move forward by 60 minutes. DST ends at 02:00 on Sun on or before Oct 31st. bruce_dev />
We’ve recently adjusted this list having learned of some additional DST rules. If you find that none of these standard timezones work for your location, tell me about it. I can add a new timezone (or fix an error) as easily as I changed “Daylight Savings Time” above.
If this doesn’t do it for you, you can define a custom timezone. This is all described in the Registry Key Assignments document the current version of which is built into the DCP and distributed with every JNIOR.
You can open the DCP by pointing your browser to your JNIOR and use the F1 key to bring up the documentation. A whole section on Custom Timezones and Timezone Corrections can be found in the Table of Contents.
In fact I can put the current version of RegistryDoc.html and RegistryDoc.css (and also inputs.png) in the public web area on the HoneyPot unit. The HoneyPot is a JNIOR Model 410 that we have connected directly to the Internet for security testing. That means that you can also retrieve pages from it. I’ll try to remember to keep that copy current.
Here’s a link to the Timezone section.
http://honeypot.integpg.com/RegistryDoc … e.timezone
So now on the HoneyPot we have the Registry Key Assignments document: http://honeypot.integpg.com/RegistryDoc.html and an application that maps all of the illegal login attempts that mostly result from malicious bots like that Mirai Botnet: http://honeypot.integpg.com/map.php