Canalplan Bug Tracker



Anonymous Login
2017-10-18 15:55 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000206Canalplan Route Planningpublic2017-06-12 20:08
ReporterNoggin 
Assigned ToNick Atty 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformPCOSWin10OS Version10
Product VersionProduct Build 
Target VersionFixed in Version9.29 
Summary0000206: Part-Day travel hours sometimes count as an extra day, sometimes not.
DescriptionWhen entering Start/Finish and "Furthest Place" , I chose 4 days INCLUDING just 4 hours travel on the last day. This worked correctly - got info "for each of 3 days plus 4 hours on the last morning."

Choosing one of those furthest place options and clicking on PLAN THIS TRIP the info is "for each of 4 days plus 4 hours on the last morning.", and the hours per day is slashed. The total number of hours seems to stay the same, it just splits the hours up between differing numbers of days.

To get the correct information, the workaround is to return to the beginning and choose 4 days PLUS 4 hours travel on the final day!

Obviously, both methods cannot be right.
Steps To ReproduceHome Page > Plan a Journey from LH Menu.
Choose start and finish as "Calcutt Top Lock No 1"

Add in: Trip length settings
Trip length 4
Hours first night (first part-day's travelling): 0
Hours last morning (last part-day's travelling): 4

Click "Furthest Place". Choose one of the results (e.g. Coventry basin terminus" and click " Plan this trip". Note the number of days and number of hours per day!
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000793

Nick Atty (administrator)

Historically there have been a number of problems with how the day count works with days on the end. I thought I'd got rid of the last one a year or so ago but obviously not. It's actually the furthest place calculation that is wrong I think (there's an argument both ways, but you have to be consistent and I've gone for these hours being extras (so the days is "full days"))

Thanks!

~0000794

Noggin (reporter)

Thanks Nick. I'm in agreement about the hours being over and above the day count. Sounds like one of those problems that just gets chased underground (underwater?) and pops up somewhere else!
Stephen

~0001075

martin (reporter)

Nick - agree with extra hours being added to the day count. Another example of when the furthest place gets it wrong.

Furthest place 10 days of 5 hours - OK.
Furthest place of 10 days of 5 hours + 8 hours on last day = 9 days + 8 hrs ( so I've lost a day )

Martin

~0001091

Nick Atty (administrator)

Yes, looking at the output I've gone to great lengths to explain what furthest place is doing, but it's doing the wrong thing! Will add this to the upgrade to furthest place.

~0001098

Nick Atty (administrator)

I actually had specific code to make it do this - calculating a new day count only when doing furthest place. Heaven knows what I'd been thinking when I did it.

Now fixed in release 9.29.9

~0001119

Autoclose (administrator)

Closing automatically, stayed too long in feedback state. Feel free to re-open with additional information if you think the issue is not resolved.
+Notes

-Issue History
Date Modified Username Field Change
2016-10-14 03:38 Noggin New Issue
2016-10-14 06:57 Stephen Atty Assigned To => Nick Atty
2016-10-14 06:57 Stephen Atty Status new => assigned
2016-10-14 07:16 Nick Atty Note Added: 0000793
2016-10-14 07:35 Noggin Note Added: 0000794
2017-04-07 09:53 martin Note Added: 0001075
2017-04-17 08:54 Nick Atty Note Added: 0001091
2017-04-21 10:08 Nick Atty Status assigned => resolved
2017-04-21 10:08 Nick Atty Resolution open => fixed
2017-04-21 10:08 Nick Atty Fixed in Version => 9.29
2017-04-21 10:08 Nick Atty Note Added: 0001098
2017-05-21 10:30 Autoclose Note Added: 0001119
2017-05-21 10:30 Autoclose Status resolved => closed
+Issue History