Hi Thorsten,
Thanks for mentioning this. Your mail had more diagnostic value than you perhaps realized. It turns out that I had the option --time-match-local included in my .fgfsrc file. Commenting out this option from .fgfsrc makes both --timeofday=dawn, as well as --start-date-gmt work again. Originally, the order of precedence was that command line options specified in .fgfsrc should be overridden be values specified on the command line, so in this particualr case, --timeofday should override --time-match-local. I haven't tested --start-date-gmt yet, but I assume that a similar problem occurs here. My tests sofar point to commit b1c7495 (Sunday Oct 16: 19:35), as the commit where overriding the --time-match-local option stopped working. I had a quick glanch at the changes but haven't been able to determine how this may happen. I hope that James has some ideas. In any case, you mentioning that it still worked on your system set me off thinking about what might have been different on my system, which made me realize that the overriding of options was a probable cause. So thanks for that. Regardless, I would like to keep the ability to set a default in fgfsrc and to be able to override it on the command line. > > Durk, for me, it does still work. However, it's all a bit fragile. The > are no error messages and any typo warps you to some random time. Also, > we're using signed 32bit integers for the time offset - so things will > break on 2038:01:19 ;-). Hmm, yeah that's not good. Do you think that switching to time_t would suffice for the "millennium bug"? > > I have a patch which cleans up the time/date option parser, adds proper > checks and messages, also extends the time type to 64bit. Also makes it > possible to use partial dates/times. "--start-time-gmt=2010" would only > change the year then - but keep the current month/day/time. Okay, that sounds good. Would your patch also be able to only set the month, day (etc), without touching the other values? > > I could push that right away - but I'll delay that for later today, to > not complicate your current hunt ;-). > If this only touches the function that computes the date itself, I'd say go for it. My tentative conclusion is that it's not the time parsing function itself that's causing problems, but a conflict between multiple command line options. But, maybe we should give James a chance to have a look before complicating matters further. Cheers, Durk ------------------------------------------------------------------------------ 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
