I've tried to reset my clock by setting the local time on my aircraft, and then saving it with a title and making it the default flight. I'm in the eastern time zone and the offset to GMT should now be 4 hours, but it is still showing 5. I cannot get it to show the 4 hour difference. I wonder if this is because DST now comes earlier and FS9 doesn't yet recognize it? Thoughts?

Yes that's a possible reason, but I have seen this happen many times before the times were changed...

FSRealtime http://www.3dsoftworks.net/products/fsrealtime/Also includes a file World Time Zones which fixes the fault with FS9's time zones. I believe it's donationware but works great as freeware.

I just purchased FS Realtime but can't figure out how to get the offset to -4 hours. Every time I make a change in FS Realtime either the local or GMT time syncs to -5 hours??? In other words (for instance), I can't get the local time to be 1500 and the UTC to be 1900.

It's because FS9 is hard coded to DST being April instead of March.

FS9 has no direct way to set the start/stop day of DST. FS Realtime includes some timezone correction files (TzFiles04). To get around the limitation, the author provides a file-switcher, DSTorSTD.exe. That util reads an ini file which has the start/stop days for DST. You would need a new DST version of the US/CAN correction bgl files as well as updating the ini. The files can be created using the FS2000 bglc documentation. SCASM also incorporates this. To get around the hard-code dates, you would set daylight_saving to False (0) and enter the zulu_bias as 240 (for EDT).FSX natively provides the capability to enter DST start/stop days in timezone correction bgl files via bglcomp.scott s..

Thanks everyone for your replies. This is the answer I got from the authors of FS RealTime."The Energy Policy Act of 2005 (which went into effect in March 2007) changedthe time of year at which we switch between Daylight Savings Time (DST) andStandard Time. Now, DST starts on the second Sunday of March and ends onthe first Sunday of November. Flight Simulator was programmed to switchbetween DST and Standard Time before the Energy Policy even existed. Thatmeans that the simulator uses the old transition dates which states that DSTstarts on the first Sunday of April and ends on the last Sunday of October.The old transition dates are the one that are hard-wired into the simulatorand unfortunately, it is not correctable as Microsoft is not releasing anynew patches for their older flight simulator products. Therefore, for thetime being, the simulator is sending the wrong time zone data to FS RealTime. It will occur any time the transition between Standard Time and DSToccurs.The good news is that this is only a temporary inconvenience as the problemwill correct itself on the first Sunday of April. The same will happen againin late October when the simulator will change back to Standard Time earlierthan the actual change to Standard Time occurs resulting in the same type ofself-correcting temporary error. The only workaround I can suggest for the time being is to set the simulatortime to a time prior to the simulators switch to Standard Time or DST."

OK I did a hack of the TZfiles04 and got basic functionality. It needs someone to do the detail work (for example, Canada, Bermuda, etc).The following code I extracted from default timezone.bgl and modified for DST:

;  File created by tzencodeFS9.py 14 Mar 2012 12:16:03mif( [$Version < 285] )   Error( You need at least SCASM version 2.85 to compile this code )mifendSet( FSVers 0x800 )Set( BUF 8192 )Header (1 50.0 22.583 -53.0 -125.679 )LatRange ( 22.583 50.0 );  GM RecNo 0;   TZ UTC -5.0 ESTTimeZone ( 44.99999095 23.99998784 -67.80000016 -84.74999383 240 10 0 );  GM RecNo 1;   TZ UTC -6.0 CSTTimeZone ( 48.99998903 25.99999610 -84.79999110 -103.00000191 300 10 0 );  GM RecNo 2;   TZ UTC -6.0 CSTTimeZone ( 28.99999894 25.99999610 -100.00000522 -103.00000191 360 20 0 );  GM RecNo 7;   TZ UTC -6.0 CSTTimeZone ( 31.99998401 28.99999894 -103.00000191 -105.00000715 300 20 0 );  GM RecNo 11;   TZ UTC -8.0 PSTTimeZone ( 48.99998903 31.74999006 -113.99999902 -124.99999478 420 10 0 );  GM RecNo 12;   TZ UTC -7.0 MSTTimeZone ( 36.16665088 30.99998910 -113.99999902 -114.66666698 420 20 0 );  GM RecNo 13;   TZ UTC -7.0 MSTTimeZone ( 48.99998903 31.74999006 -103.00000191 -113.99999902 360 10 0 );  GM RecNo 14;   TZ UTC -7.0 MSTTimeZone ( 36.99999511 30.99998910 -109.08333778 -113.99999902 420 20 0 );  GM RecNo 23;   TZ UTC -5.0 ESTTimeZone ( 35.33332508 33.49998593 -84.79999110 -85.50000384 240 20 0 );  GM RecNo 39;   TZ UTC -7.0 MSTTimeZone ( 41.74999416 36.99999511 -101.50000289 -103.00000191 360 20 0 );  GM RecNo 40;   TZ UTC -5.0 ESTTimeZone ( 38.49999703 37.99999002 -85.99998996 -87.00000286 300 20 0 );  GM RecNo 41;   TZ UTC -5.0 ESTTimeZone ( 38.49999703 37.99999002 -84.79999110 -85.99998996 240 20 0 );  GM RecNo 49;   TZ UTC -5.0 ESTTimeZone ( 40.74999891 38.49999703 -84.79999110 -87.53333285 300 20 0 );  GM RecNo 50;   TZ UTC -5.0 ESTTimeZone ( 38.49999703 37.99999002 -85.99998996 -87.00000286 300 20 0 );  GM RecNo 51;   TZ UTC -5.0 ESTTimeZone ( 38.49999703 37.99999002 -84.79999110 -85.99998996 240 20 0 );  GM RecNo 56;   TZ UTC -7.0 MSTTimeZone ( 46.74998716 41.99998811 -113.99999902 -116.99999616 360 20 0 );  GM RecNo 59;   TZ UTC -7.0 MSTTimeZone ( 42.99998302 41.74999416 -100.74999288 -103.00000191 360 20 0 );  GM RecNo 62;   TZ UTC -5.0 ESTTimeZone ( 46.99999887 41.75832611 -84.79999110 -87.00000286 240 20 0 );  GM RecNo 63;   TZ UTC -5.0 ESTTimeZone ( 41.16666198 40.74999891 -84.79999110 -87.00000286 300 20 0 );  GM RecNo 64;   TZ UTC -5.0 ESTTimeZone ( 41.75832611 41.16666198 -84.79999110 -86.49999619 300 20 0 );  GM RecNo 72;   TZ UTC -7.0 MSTTimeZone ( 45.94999116 42.99998302 -100.49998999 -103.00000191 360 20 0 );  GM RecNo 76;   TZ UTC -4.0 ASTTimeZone ( 49.99998394 42.99998302 -52.99999997 -67.80000016 180 10 0 );  GM RecNo 77;   TZ UTC -5.0 ESTTimeZone ( 45.49999796 43.99999604 -66.99999288 -67.80000016 240 20 0 );  GM RecNo 84;   TZ UTC -7.0 MSTTimeZone ( 47.58333106 45.94999116 -100.99999711 -103.00000191 360 20 0 );  GM RecNo 88;   TZ UTC -5.0 ESTTimeZone ( 46.99999887 44.99999095 -67.80000016 -69.99999002 240 20 0 );  GM RecNo 94;   TZ UTC -7.0 MSTTimeZone ( 48.99998903 47.99999412 -113.99999902 -116.00000381 360 20 0 );  GM RecNo 95;   TZ UTC -7.0 MSTTimeZone ( 47.99999412 46.74998716 -113.99999902 -115.49999714 360 20 0 );  GM RecNo 97;   TZ UTC -6.0 CSTTimeZone ( 48.99998903 47.58333106 -103.00000191 -104.04999018 300 20 0 );  GM RecNo 100;   TZ UTC -5.0 ESTTimeZone ( 47.99999412 46.74998716 -87.00000286 -89.74999711 240 20 0 )

This I assembled using the SCASM assembler into a bgl, dsttime.bgl. Next, I copied this file into the TZFiles04 scenery folder (under FSRealtime). Then I copied the default file timezone.bgl from sceneryBasescenery into the same scenery folder and deactivated the default one by changing extension from .bgl to .b. Then I edited the file DSTorSTD.ini in the TZFiles04 scenery folder by adding two entries (10 and 11) into each section. I probbly have the parameters off by a bit. I once figured out the exact definition of each one but didn't write it down and forgot. Experimentation by changing the dates will solve that easily enough.

[DST]0=ArgentD,120,Argentina,12,1,7,0:0:01=Aus930d,-570,Australia (Adelaide),10,1,1,2:0:02=Aus1000d,-600,Australia (Canberra/Melbourne/Sydney),10,1,1,2:0:03=Brazil_d,120,Brazil,10,1,2,0:0:04=Cht1245d,-825,Chatham,10,1,1,2:45:05=Falkd,180,Falklands,9,1,1,2:0:06=Namibia_d,-180,Namibia,4,1,1,2:0:07=Nz1200d,-780,New Zealand,9,1,6,2:0:08=Parach_d,180,Chile,10,7,2,23:59:599=TAS1000D,-660,Tasmania,10,1,1,2:0:010=dsttime,240,United States,3,2,1,2:0:011=dsttime,240,United States East,3,2,1,2:0:0[standard]0=ArgentS,180,Argentina,3,1,3,0:0:01=Aus930s,-570,Australia (Adelaide),4,1,1,3:0:02=Aus1000s,-600,Australia (Canberra/Melbourne/Sydney),4,1,1,3:0:03=Brazil_s,180,Brazil,2,1,3,0:0:04=Cht1245s,-765,Chatham,3,1,3,3:45:05=Falks,240,Falklands,4,1,3,2:0:06=Namibia_s,-120,Namibia,9,1,1,2:0:07=Nz1200s,-720,New Zealand,4,1,1,3:0:08=Parach_s,240,Chile,3,7,2,23:59:599=TAS1000S,-600,Tasmania,4,1,1,3:0:010=timezone,300,United States,11,1,1,2:0:011=USAEAST,300,United States East,11,1,1,2:0:0

The reason for two entries is TZFiles04 includes a file USAEAST.BGL and that needs to be turned on and off as well. I don't think that file is needed anymore with this hack, but I left it there just in case.So now, when you run DSTorSTD, it will turn on/off my dsttime file (*.BGL = on, *.INACTIVE = off), the TZFile04 USAEAST file, and the moved, default timezone file.Note that this fix I did only for US but timezone.bgl also covers Europe. I'm thinking you could probably change the DSTorSTD.ini file so my file is only active between 2d Sunday of March and 1st sunday of April, and again from 3rd Sunday in October to 1st Sunday in November so that Europe isn't affected.It seems to more or less work, but in working on FSX I found that fixing the problems was so much work it was easier to start all over from scratch (which I am doing).scott s..