On 29 Oct 2011, at 18:36, Durk Talsma wrote: > I think that it's a fairly recent commit that broke this: I'm using the > --start-date-gmt option quite frequently, and it wasn't until earlier this > week that I noticed an inconsistency (although I hadn't conciously noted any > time shift yet, I did notice that startup patterns for traffic were fairly > inconsistent). On a more general note, I have reason to believe that this is > a more general time issue: I just found out that --timeofday also gives the > wrong result: I just tried running --timeofday=dawn, and that put me at > approx: 2011-10-29T:17:30 for Amsterdam (EHAM). Given that we're currently 2 > hours behind UTC, this is not dawn, but already after sunset.
While I recently touched the options.cxx code, I would be 'surprised' if that's broken the options above, given that other single-value options work. (It's just passing a string through, and the functions that process the args are unchanged) What's more likely, is that some of my refactorings in the TimeManager code would have upset it, *except* that I made all those changes pre 2.4, as far as I can recall - and certainly more than three months ago. Durk, it sounds like the window of this occurring is quite 'tight' - less than seven days - so I'm really unsure what it might be. James ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
