Preparing for real time

Flipper

Member
Joined
Feb 4, 2005
Messages
11
I have heard that LBP will support the real time format in the future and I have a couple of question:

1. Any estimate on when this will happem?

2. My time is partly in the decimal format and partly in real time (Some logged in the States and some in Europe). My current software supports this and even when I switch between the two formats the software remembers the original format and uses that to ad hours together. That way totals don't change like they would otherwise. When importing into LBP my totals change regardles of what way I am importing. I have thought about importing the data into Access or Excell and then changing the time from real time to decimals with a lot of decimals (ie 22min = 0.36666666666666). I know LBP just makes this into a number with one decimal, but does it use all the decimals for calculating totals?

3. Is the above a good preparation for the future format or is it better to erase the data when the new format arrives and reimport the data?

4. Will the new format support having logged time two different ways?
 
Hello,

There is nothing to publicly announce about future versions as when I announce dates, I'm guaranteed to not meet them! Therefore it's best to just make the best of what we have and when there is information to announce, that's when it will be announced. This prevents the aingst of customers waiting for the next version or prospective customers thinking something is coming out and therefore holding off with the logbook entries.

Typically the format you see, whether hours:minutes or hours.tenths is formatted for your presentation but stored as the same value, which is why you should be able to switch between formats and always go back and see the same. Logbook Pro should be storing the decimal values to the level you input, i.e. hundredths, tenths, etc. however is formatted to only shows a hours.tenths. Calculations vary as far as their accuracy, expect only to be at the tenth but typically the raw data is added and then formatted out to the displayed format.

22 minutes is going to be formatted withina time range to display a number of tenths, it's not mathematical as you may think. Here is a thread on a similar topic.

I can't comment on what the new version will or will not have as it is subject to change and too early in development to tell.

NCSoftwareSignature.gif
 
In my case it makes quite a difference. I loose about 30 hours in the conversion to tenths versus real time.
 
I am not that worried about the 30 hours for total time calculation, but you look extremely unprofessionally in an Airline interview situation if your military record doesn't compare with your logbook.
 
Your fear of how you would look in an airline interview is probably well founded and in that respect I hope you can resolve the issue in your favor. Reporting less time than you have and being able to explain why the difference exists will demonstrate integrity on your part.
 
The issue here 'I believe' is that you are converting minutes to hours.tenths in a system that is not precise as you are expecting. Take a look at the system where the tenths are calculated between a range of numbers, and if your minutes come out to the high side in all the increments, sure, it can add up to what you perceive as a loss, but it's not really a loss. You are simply on the same scale as everyone else. What we really have is a disparity between the way people log hours and there is going to be a diversity, some to an advantage to a small degree, some not:

Take for example we go out and fly 1 hour and 44 minutes (1:44).

If you use the gov't time system, you will log this as 1.7. Now the range for the .7 is 40 to 45 minutes. I could have flown a 1:40 or a 1:45 and still logged a 1.7. But there is a 5 minute window of difference here. You logging in minutes are going to accumulate that window range of minutes, which over years certainly can add up to more time, and in your case, probably a contributor to the disparity.

There are people that log in tach time (which I hear is not accurate) and want to log down to the hundredths, people log off of hobbs time which rolls over every 6 minutes and I'm sure you've heard of people watching that hobbs meter getting ready to drop to the next tenth and log the additional tenth, in this case, they just gained the next 6 minute window in one second of time! As you can see, flight times can be diverse, and in your case, the difference to justify is simple in explaining this very thing; you logged in minutes, your data was converted to tenths, and due to the 5-6 minutes window used per tenth, depending on the various systems out there (and there are several more not yet discussed) you are going to have a disparity no question about it.

The best thing to do now is log your takeoff to landing times and there are plans to use this for more accurate transfers to the real time format. The problem that is going to come into play here is are you going to want your prior entries changed? My personal preference, i.e. my logbook, I would not, I don't want anything changed from what I logged in the past. But this is a system that is going to be looked at carefully and thoroughly to ensure a flexible, optional system is in place when the additional time formats are added in the next version, which will be several per the specifications in place now.

I hope this sheds some light on this issue with a little more in depth study of the situation.

NCSoftwareSignature.gif
 
I am not really worried about loosing time. It is more that my logbook doesn't match the printout from my Air Force.

Looking forward to the changes. When you make it possible to ad/display entries in hour:minute format you are opening up your logbook to a huge market. It is truely the best software out there except for this litte fairly important detail.

Better get bussy, you are loosing money as we speek ;o)
 
Back
Top