On the time display issue

[Mysterious Pilot]

I noticed a small flaw in phpVMS with regards to the difference between the system's representation of time and the visual presentation of that time.

Some time ago for example I pointed out that in the Schedules form it asks the administrator to enter the duration of the flight in HH:MM format (which is actually the best). However, when this same form is displayed again for editing, the original HH:MM is displayed in a format that contradicts the instructions of the program, i.e.

During creation

     Flight duration:  00:30
                       Please enter time in HH:MM format

During Editing:

     Flight duration:  0.5
                       Please enter time in HH:MM format

Or if I enter a duration of 00:20 rather than displaying 00:20 (the format it requests) or 0.333 (wrong format but the actual equivalent in decimals) it displays the wrong value, "0.2". Let's not redefine arithmethic :-) 0.2 is the same as 2/10 which is quite different that 20/60 (an hour has 60 minutes).

This same flaw appears in other parts where the system displays time, such as in the Pilot's center banner, I performed a flight of 30 minutes (00:30) and rather than displaying I have flown 00:30 or 0.5 it displays 0.3 which is wrong.

IMHO the system has to be consistent in its display and interpretation. It asks the user to enter in HH:MM (a format which most humans are familiar with) but it displays it in a different format (even for editing), thus contradicting itself (and confusing the user) and in doing so, also displaying the wrong information.

I hope I am not stepping on anybody's toes, this just a remark with the only purpose of making phpVMS a better system than it already is. Nobody is perfect and we users are here not only to use but to test the things that may have escaped the developer.

[Mysterious Pilot]

During creation

     Flight duration:  00:30
                       Please enter time in HH:MM format

During Editing:

     Flight duration:  0.5
                       Please enter time in HH:MM format

I looked at it in more detail and have confirmed (see attachment) that the PIREP timestamp field in the database has the correct duration timestamp but at that very moment the PIREP is saved an incorrect action is commited by wrongly interpreting a value that is in the base 60 domain as a value in decimal base without applying the conversion factor and this incorrect value is then applied to the flightime field which is what is used to compute (accumulate) pilot hours.

The test case (my single PIREP) has the log stating that departure was 22:45 and arrival 23:18, that is 32 MINUTES not 32/100 of an hour (0.32).

In other words, the software does this with the duration HH:MM:SS

FlightTime = HH + MM / 100

instead of this

FlightTime = HH + MM / 60 + SS / (60*60)

This anomaly (the bug) is caused by Lines 741 and 742 in function fileReport of the PIREPData.class.php file (the PIREPData class) where it does this:

	/* Proper timestamp */
	$flighttime_stamp = str_replace('.', ':', $pirepdata['flighttime']).':00';
	$pirepdata['flighttime'] = str_replace(':', '.', $pirepdata['flighttime']);

<--- BUG

So, initially the flighttime field in the pirepdata array is correct, i.e. something like 00.32.00 (hh.mm.ss) and gets reformatted (not converted) to a proper timestamp (00:32:00). The problem ocurrs when this gets re-reformated (back to the same) to 0.32. At this moment this should have meant 0 hours 32 minutes but it is simply stored as 0.32 HOURS (which is not the same). As a result ALL displays of pilot flight times are incorrect.

It is not clear what the exact string is when the pirep comes, 00:32 or 00:32:00. What is obvious is the simple reformatting of replacing the '.' for ':' and viceversa without actually applying the conversion to the numerical domain (base 60 to base 60).

By the way, the same erroneous pattern is exhibited in the creation and editing of schedules. User is asked to enter duration in HH:MM format (00:45) but it gets stored in the database field 'flighttime' as 0.45 (45 minutes is equivalent to 0.75 in decimal base) and then when presented back to the user during edit/display it is shown as 0.45, in other words, wrong notation (contradicting what is asked of the user and the format people are used to) and wrong value as well because if it was going to contradict notation then it should display 0.75 (rather than 0.45) or 00:45.

Extra Note (on a slightly different interpretation for a fix):

Looking a bit better into the issue, the db value is 00.32. So if you actually meant to store it as that HH.MM rather than decimal hours then the problem is with the REPRESENTATION of this value when it is presented back to the user (on the web browser) rather than presenting as decimal, replace the decimal point by ':'. This is perhaps an easier fix than assuming the flighttime field is in decimal domain, otherwise for the upgrade you would have to provide a script to correct all values in the database.

Sorry for being so thorough in my observations and system test :-) Like I said, nothing personal, in my (former) life as a programmer I know how easy it can be to get carried out and forget about little things among so many distractions.

Edited December 13, 2010 by Mysterious Pilot

[Nabeel]

The flighttime column isn't used internally anymore, only the flighttime_stamp. As long as the flighttime_stamp column is correct. I haven't removed that column yet, but I will be for the next version. But as of the previous version, it's not used anymore.

From the PIREPs it always comes as HH:MM:SS I believe. There's only a reformatting of a time if it's been typed in. Times are *not* stored as decimal as you indicated. It's always in HH:MM:SS format. If you're seeing decimal formatted time anywhere, then that's a bug. I'm not sure where else you got decimal time notation from.

It's in HH:MM:SS format to allow MySQL to do any time summations, and I don't have to handle that. It comes from ACARS as HH:MM:SS format as well.

During editing, if it's reverting to decimal format, then that's a bug.

[Nabeel]

I also replied to your bug report, as a comment

[Mysterious Pilot]

Ah, didn't know there were legacy columns in the database. But we are converging to a much simpler solution which limits itself to the presentation layer where the timestamp (in PIREP and Schedules) has to be presented to the user in the correct format (HH:MM) rather than decimal. Much easier fix.

Will wait for next upgrade for the rollout, I suppose I can assume that is fixed in the next release, right? and Thanks for the response.

[Nabeel]

Ah, didn't know there were legacy columns in the database. But we are converging to a much simpler solution which limits itself to the presentation layer where the timestamp (in PIREP and Schedules) has to be presented to the user in the correct format (HH:MM) rather than decimal. Much easier fix.

Will wait for next upgrade for the rollout, I suppose I can assume that is fixed in the next release, right? and Thanks for the response.

It's always in HH:MM. Not sure where you're getting decimal from. The timestamp column remains as 0.42 if noted as 42 minutes. There's no conversion anywhere.

The only update is dropping that column, and casting flighttime_stamp as flighttime. There's nothing else to fix. And as for a timeframe, not any time soon.

[Mysterious Pilot]

It's always in HH:MM. Not sure where you're getting decimal from. The timestamp column remains as 0.42 if noted as 42 minutes. There's no conversion anywhere.

I looked right into the database to see how they were stored. Also looked in the obvious places (the web forms) where the duration is always displayed in x.y format leading the user to believe it is a decimal rather than xx:yy which would reflect the actual value stored in the database.

The only update is dropping that column, and casting flighttime_stamp as flighttime. There's nothing else to fix. And as for a timeframe, not any time soon.

I think we disagree there :-) the fix is in the visual (presentation layer), durations (flight time, total flight hours, etc.) which appear in several web pages, should read HH:MM rather than X.Y (decimal form).

[Nabeel]

I looked right into the database to see how they were stored. Also looked in the obvious places (the web forms) where the duration is always displayed in x.y format leading the user to believe it is a decimal rather than xx:yy which would reflect the actual value stored in the database.

I think we disagree there :-) the fix is in the visual (presentation layer), durations (flight time, total flight hours, etc.) which appear in several web pages, should read HH:MM rather than X.Y (decimal form).

Then the text on the template should be updated. That's something you can do in your templates for now, to indicate the time format. If you want, you can also add the str_replace() code into the templates to change that formatting. And the casting in SQL with flighttime_stamp AS flighttime will fix the issue in the presentation layer, as it's just passed through, and there's no formatting done. If you wish, you can add that now as well to the getPIREP() and findPireps() functions in the PIREPData class

[Mysterious Pilot]

I added this to the Utility class (Util) in the classes directory:

	/*
 * Format time duration in HH:MM rather than present it as it comes
 * from the database (H.M). Otherwise users assume the duration is 
 * in the decimal base. The format includes a minimum (zero padded)
 * of two hour digits but automatically adds more as the number of
 * hours grow beyond 100.
 */
public static function FormatDuration($duration)
   	{
    	$hours = intval($duration);
    	$minutes = intval(($duration - $hours) * 100);
	// adjust the number of hour digits
    	$hfl = 2;
    	if (strlen($hours) > 2)
    	    $hfl = strlen($hours);
    	$format = "%0" . $hfl . "s:%02s";
    	return sprintf($format, $hours, $minutes);
}

And in the files (some templates, etc.) such as layout (but there are many others) I use this:

<?php echo Util::FormatDuration($userinfo->totalhours); ?>

Instead of just this:

<?php echo $userinfo->totalhours; ?>

Of course, this goes for totalhours, transferhours, in layout, user profile, vastats etc. Of course, if we are going to reinvent the display of time (like that Swiss Swatch company tried to do years ago) is another thing :-)

[Nabeel]

Thanks, I'll take a look when I get a chance. Can you add a comment to that bug?

[Jetwave]

I'm currently testing out my phpvms, I installed it just a few days ago so its the latest version, but I'm experiencing this problem as well and all I keep finding around the forums is 'this issue is fixed in later versions' but its obviously not.

Regardless, I would prefer ALL timestamps to be displayed in decimal format (duration, logged time, total time, etc) so 0.5 = 30 minutes not 50, and the Pirep wont flag me when I enter a value over 60.

Is there a solution or does anybody have a utilclass they have config'd to work this way? At a minimum I would like to get rid of the H.MM format, that is just improper.