Ah, I've figured it out:
The time response coming from server2.netinfostation.com is:
13390343 1339034354 01:59:14 Jun-07-2012.
We've already concluded that the second value is the epoch, which sets the date and time to the application. Now... the first number is supposed to be an offset in seconds. Yes, I know it's just the first eight digits of the epoch, that's why the app doesn't
work ;-)
The number above works out to about 155 days. The actual offset should be like 0.9 (probably some delay measured based on the processing of the request).
I've found that server1 does give the correct time response. So I've hacked the executable to make it connect to server1 instead of server2. You can download it (at your own risk, of course... and don't blame me for the bad weather!) from:
http://www.fraservalleysoftware.com/download/5-day forecast.exe
Now what does that mean? There's some very confusing difference between server1 and server2 in the time response. On purpose? Who knows. Did the URL for server 2 used to be redirected to server1, but now because of the move it isn't? Who knows... But at
least I expect my fix to help everybody out till the guys at Forecast finished their "move" :-)
Stefan Viveen
Fraser Valley Software
Hope, BC Canada
Awesome work - I had thought that something was wrong with my system. I had run the program in safe mode and it reported the actual date/time, but that was because it couldn't connect to the internet and used the system date/time.
If your taking requests to further the functionality of the product and also unsure how much of the executible you've been able to decypt. Could you change the update cycle from 12 hours to 1 hour? I am just running a BAT file through task scheduler that
kills the running process and starts a new one.
Again thank you very much to stepping up and fixing the problem!!!