I have been using Thompson's timezone bgl's for years and have found them to be spot on for most of the world but they are off by one hour in many parts of the continent of Africa. He is no longer active nor providing updates so I am attempting to tackle it myself. I had created an entire world-grid timezone layout for FS98 using that older bgl format with scasm but I am having great difficulty finding a process to disassemble the FSX SP2 bgl's to xml. I have used the programs from the internet as well as using the SP2 SDK disassemble program but none give me a total source code detail - only headers. I am obviously not experienced in working with the SDK and am posting in hopes that one of you gurus could give me some direction. All I want to do is decompile several of the bgls so that I can correct the errors in longitiude/latitude and then recompile them. I know how to create entirely new ones but there must be a way to get a detailed xml source code from a bgl. I am at a loss on how to accomplish this. Please help! Thank you.Craig

Other than the section type appears to be 0x2F and the section data starts at 0x5C in timezone.bgl I don't think anyone has ever attempted to decode it. Given that the data only use 3360 bytes I assume that it is gridded somehow, like magdec is. I don't know that timezone data is located anywhere else?scott s..

Hi Scott! That is the question! I know that Thompson must have been able to decode so he knew what fixes to apply for FS9. Also since I cannot decode his files either, he must have used the same compiler procedure as FSX. I tried the old SCDIS program that worked with FS98 but that also brought up nothing but a header and no detail sections. No one has been able to communicate with Thompson. He seems to be totally off the radar. He has one file for the entire continent of Africa and it is right according to latest timezone data except for the south central border btw UCT+1/UTC+2 which puts 3 countries in the wrong timezone. If no-one has a solution for the decode, I would have to rewrite the XML file for the entire continent and use priority=255 since I assume he probably used the same priority. Anyway, I guess I am rambling on here. But if you come across any possible work-around PM me. Thanks.

Edited February 14, 201214 yr by HiFly

Did some work on this. So far it appears each section record is 24 bytes. The first record is at file offset 0x5C (92). The recod I have so far:0x00 DWord Long Min0x04 DWord Lat Max0x08 DWord Long Max0x0C DWord Lat Min0x10 Int timedeviation minutes0x12 byte priority0x13 byte daylightSavingsTimeShift0x14 byte SavingsStartDayOfYearBase (ls 8 bits)0x15 byte SavingsEndDayOfYearBase (ls 4 bits) SavingsStartDayOfWeek (3 bits) SavingsStartDayOfYearBase (ms 1 bit)0x16 byte daylightSavingsEndDayOfWeek (3 bits) SavingsEndDayOfYearBase (ms 5 bits)0x17 byte unk (00?)Do you have the lat/long for the area that needs to be corrected in the TZ04 Africa.bgl (assume that's what you are referring to?)scott s..

Edited February 16, 201214 yr by scott967

I haven't really tested this, but the SDK indicates you could just make a correcting BGL and put it in the Addon folder.

<?xml version="1.0" encoding="ISO-8859-1"?><FSData	 version="9.0"	 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'	 xsi:noNamespaceSchemaLocation="bglcomp.xsd" ><TimeZone	  latitudeMinimum = "N47.0"	  latitudeMaximum = "N48.0"	  longitudeMinimum = "W123.0"	  longitudeMaximum = "W122.0"	  timedeviation = "-360"	  priority = "0"	  daylightSavings = "USA"	  daylightSavingsTimeShift = "-60"	  daylightSavingsStartDayOfYearBase = "100"	  daylightSavingsStartDayOfWeek = "SUNDAY"	  daylightSavingsEndDayOfYearBase = "300"	  daylightSavingsEndDayOfWeek = "SUNDAY"/></FSData>

This is from the SDK and it compiles with BGLComp. What you are doing is specifying a rectangular lat-long area and applying the timezone info to it. It should override the default timezone.bgl for that area, I believe.Dick

I thought I was pretty familiar with the SDK but....

I haven't really tested this, but the SDK indicates you could just make a correcting BGL and put it in the Addon folder.

I haven't figured out what

daylightSavings = "USA"

is really supposed to do. I always use "NONE" and it works fine (in my test the correct offset from UCT is applied), although my systems are all set to system time HST and we never have DST so maybe my test setup is not extensive enough.scott s..

I haven't figured out what

daylightSavings = "USA"

is really supposed to do. I always use "NONE" and it works fine (in my test the correct offset from UCT is applied), although my systems are all set to system time HST and we never have DST so maybe my test setup is not extensive enough.

It specifies which region DST start and end dates should be based on. In the US, DST starts on the second Sunday of March and ends on the first Sunday of November. In the EU, it starts on the last Sunday in March and ends on the last Sunday in October.

It specifies which region DST start and end dates should be based on. In the US, DST starts on the second Sunday of March and ends on the first Sunday of November. In the EU, it starts on the last Sunday in March and ends on the last Sunday in October.

Nope, doesn't work. After a bunch of testing, that setting is not saved at all by bglcomp and isn't present in default timezone.bgl. As far as the TzFiles04 addon, that is setup according to the FS2000 BGLC opcodes and only provides a DST boolean value yes/no. I don't know what FSX does if it reads the DST bool as true in those files, but don't care as I am using the FSX bglcomp which provides specific control over start/stop dates for DST.I aslo see that the default timezones (without even timezone.bgl) are off by 7.5 degrees west. That is, for example the west coast US is in UTC -8 and that should end (flying west over the ocean) at -127.50 to UTC-9. Instead, it doesn't change untiil -135 (i.e., 1/2 a timezone off).From my testing it doesn't matter to FSX what your local system timezone is set to. I think if you select the "use system time" option, FSX reads your computer local time and date, and using its internal timezone data computes GMT/UTC accordingly when loading the default flight. So the initial UTC in FSX may not reflect "real world".I've redone the default timezone.bgl so it properly starts/ends DST but that file only covers US and Europe. so it's pretty much crap. And it is wrong in some particulars (mainly I think state of Indiana which changed its DST rules).scott s..

Edited March 5, 201214 yr by scott967

Hey, Scott, you obviously are a very experienced programmer. I have been silent for a week because I just installed an update to UT2 which professed to have a current update of timezone.bgl for the entire FSX world. First two airports I went to were off by 2 hours so I scrapped it and temporarily am back to FSX default +TZ4 but there have been drastic changes in the way boundaries and DST dates in the last 18 months that require a major redo of the entire FSX world. Check out this website (which is the most current and authentic international site for timezones): www.worldtimezone.comFor example all of Russian timezones have now gone to DST year-round; Belarus has gone from UTC+2 -> UTC+3 and of course the African changes we spoke of earlier. Also Faukland Islands are now DST year-round and it looks like Egypt no longer uses DST but remains UTC+2 year-round; Venezuela is now UTC+4.5. Those are the major boundary changes but there are many more countries that are now using DST in N and S Hemisphere this year. Several Caribbean nations: Cuba, Haiti, Grand Turk now will use DST. And there is much more. I would certainly be willing to help build files if you would show me how to decode these things. Nothing I have works. You mentioned in Email that you had developed a disassembler (pye) that you were using. I know the format from SDK to build timezone xml files and then use bglcomp to compile but it would be much easier just to correct the areas from the default FSX and or TZ4. Some corrections just require changing DST start/end dates or in the case of Russian zones just adding 60 minutes to all the areas.This has become a major issue with me and you are the only one in many forums that knows what he is doing. Thompson has been totally off the radar for years. Look forward to any help you can give me Scott.

I decided to do my own timezone fileset to replace TZ4 ones. I looked at all those files, and while they could be made to work, they were designed for FS9 where you need separate DST files because you can't control the dates. I'm doing it in chunks, and when everything is complete will combine it all. Testing is a bear. I found a set of airports which test aspects of the first phase (for North America) but the number of different rectangles I had to create means I didn't do 100% coverage testing. I still find in some cases a timezone rectangle doesn't seem to work until I raise the priority. I don't know why that is. For now, as long as I can get it to work with higher priority I'm using it.Meanwhile someone was asking about FS9, and I took some time away to play with it. I created a US timezone file using the FS2000 documented timezone command which I assembled using SCASM. It seems to work, but I didn't really test it and on consideration, it might not be working (I disabled the default timezone file and it could be just that the hard-wired timezones is making it look like my file worked). I just don't want to spend a ton of time on FS9 timezone because it's a pain.Since I've now rested a bit I will start on the next phase which will be Europe. I've learned a few things to improve efficiency in building the rectangles, but it still isn't trivial work. The NA phase is in the library today (FSX Misc files).For testing, after spending a bunch of time I am 99% convinced that if you go to the free-flight screen and enter an airport and then look at the local date/time and GMT time, the time difference there is a valid display of what you will see in the sim in all conditions (i.e., start a flight, end a flight, overfly).scott s..

My hat off to you, Scott. It is indeed a daunting task. I downloaded your NA file but I have not been having any problems with that area using the default +TZ4 but Eastern Europe is a bear. John Goodwin (UT2) did his own set as I mentioned earlier and when I sent him my initial critique he defended it by stating that FSX had HARD-CODED the timezone info into each AFCAD and would require a rework of each individual AFCAD to fix correctly. Somehow, I just don't believe that and using ADE can't find any such entry (maybe ADE didn't decode everything, though). My thinking, Scott, was to just isolate the major change areas from TZ4 (BTW I was unable to decode those files using SCDIS) and create rectangles to correct only those areas that need updating using a higher priority. I have no idea what priority that Thompson used. I hope he didn't make them all "255". For the most part the only really big changes have occured in the Caribbean, Russia and Belarus. Oh, yes, and Venezuela has gone to UTC+4.5. As for my earlier discussed Africa problem, extensive testing of many airports verified that Thompson actually has it right for what he has done but may not have corrected that Southwest area when FSX has UCT+2 but should be UTC+1. Everyting else seems right on. I am thinking of just creating an overlay of UTC+1 strip at a higher priority over that area and all of Africa will be according to latest stats. The rest of TZ4 boundaries seem to be correct in Southern hemisphere (South American/Australia/New Zealand)! They may not need a complete redo. You have my Email, Scott. Keep me updated since I am not a developer and not usually visiting this forum. Again, thanks.Craig