paulkinzelman
Well-known member
Neal suggested I post this idea, so it's his fault. /Forums/emoticons/smile.gif
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. /Forums/emoticons/smile.gif 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.
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. /Forums/emoticons/smile.gif 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.