@belgariontheking said:
@stewieatb said:
Now i see how this happened; it seems they're using a backend time value to increase the sorting speed, and a frontend one to tell the user. Makes sense, will actually improve speed.
This doesn't make sense to me. I've never designed an RDBMS, but I would put an integer (or long) value into a date column, then display it as a date/time when SELECTed. Thus, there would be no reason for a developer to do something insane like this.
Sorry, i wasn't very clear there, but i think you got the idea. What i meant was, have a DepTime_1 column of decimal/float type, then a DepTime_2 column of time in hh:mm. If the records need to be sorted so that the emails for the day are prioritised and grouped by train, then sort by the DepTime_1 column, but send the value in DepTime_2 to the user in the email. I think you mean to have every time as a four-digit integer, then insert a colon in the middle by splicing and concetenation in the email sending script, which is a much better idea than what i think was done here. I guessed that hh:mm time values might be slow to sort, but in retrospect, this is more true of dates in a non-YYYYMMDD type format. hh:mm should (I think) sort just as fast as any other 4-digit integer. Maybe this is an assumption the original designer made without thinking about it, or asking anyone, and no-one has ever bothered to fix it. Or maybe it's just too entrenched in the architecture to fix.
An alternative explanation is that this emailing system was added onto the original booking system and is pulling its times out of a table for something else, say, ticket printing, or billing, which due to some ungodly design pattern uses a fraction of the day instead of hh:mm time. I would love to see the code that turns decimals into hh:mm time. But this still leaves the question of why the original architects chose this decimal time for their system.