Reply to thread

Message: [QUOTE="paulkinzelman, post: 5684, member: 828"] Neal suggested I post this idea, so it's his fault. [img]/Forums/emoticons/smile.gif[/img] I've never understood why software designers don't keep the internal time in UTC *always*, then convert the result to whatever time zone you want when displaying it and accepting input. And what do you do during that very confusing time in the fall when the time goes from midnight to 1am, then back to midnight, then back to 1am? Or maybe it's between 1am and 2am, whatever. How do you calculate durations of flights? And that's not to mention the legislation I just heard about today that may extend DST for another 3 weeks in the fall and or spring or something. It's enough to make me want to move to AZ where they don't participate in that particular idiocy. Especially in flying where you cross timezones, it gets very confusing. And what Neal sent out in his newsletter about handling DST was also very confusing to me, especially when he said something about when moving to a new timezone, you can't change the timezone of the program. This is going to cause a big problem if somebody moves, and the only people who move their permanent address more often than pilots are people on the lam. [img]/Forums/emoticons/smile.gif[/img] You've got to have some way to have the pilot's home base/timezone in the program be able to be moved from one timezone to another. If everything is handled internally as UTC, then the input and display might be a bit more complex, but at least the time kept internally would be without confusion. In fact, now that I think about it, in the logbook display where you have start-time, end-time, what happens when they're in different timezones? And what about the poor freight-dog who's in the air at the time we go from DST to ST in the fall where the hour repeats (like I mentioned above)? You really need a timezone designator in the 'block time' entries as well. [/QUOTE]

Verification