Inconsistent Input Handling for Trip Details

[obul-reddy610]

Description:

The trip-sharing form allows inconsistent and unrealistic input values for trip details:

Departure Date Input:

Accepts arbitrary numbers such as 243545678988 which is not a valid date format.

This can cause unexpected behaviour or system crashes when processing or displaying date-related data.

Trip Length Field:

Accepts values like 5 hours 1234 mins. The parsing logic does not seem to validate or limit these inputs appropriately.

Steps to Reproduce:

Go to the trip-sharing form.

Enter:

Departure: 243545678988 and time 09:30 PM

Trip length: 5 hours 1234 mins

Save or share the trip.

Expected Behaviour:

Departure date should only accept valid date formats (e.g., DD-MM-YYYY).

Trip length input should validate hours and minutes separately, with reasonable upper limits.

[harshitptl21]

For the Departure Date input, it's recommended that you familiarize yourself with the Unix timestamp format and its conversion to human readable format and vice versa. Its an input field you can write what you want, but that does not qualify as a bug.

For the Trip Length input, a rough time estimate is auto filled. Then, Users can adjust it further based on their specific needs and format, if required.

[Swi-ft]

Isn't that a software side issue that I can fill whatever I want tho?

[harshitptl21]

If you enter incorrect information in your address on a shopping website, it's not their responsibility if you don't receive the delivery. Similarly, if you offer a ride, others might not request it if the details aren't clear or appealing.

[obul-reddy610]

Frankly, the whole point of using software like this is to make our work easier and reduce the chance of user error — not to expect every user to be familiar with Unix timestamp formats or to guess what input formats are acceptable.

If a field accepts a wide range of formats (like departure date or trip length), then the system should provide clear guidance or validation. Otherwise, it just becomes confusing and error-prone. Saying “it’s just a text input, write what you want” misses the whole point of good UI/UX design. You mentioned in the USER MANUAL for a INTERACTIVE UI . Is this interactive??

At the very least, the software should flag unusual inputs or give a warning if something seems off — like putting “1234 mins” or a timestamp that looks nothing like a date. That’s not being strict — that’s being helpful.

Let’s not forget: software should adapt to users, not expect users to adapt to unclear software behavior.

[harshitptl21]

If the input field is paired with a calendar icon, users don't need to worry about the format—once they select a date, the correct format will appear automatically.

What's easier—"1 hr 30 min" or "1.5 hr"? The input field offers a free-format option, giving users the flexibility to enter the duration in whichever way feels most convenient for them.

[obul-reddy610]

You're absolutely right to highlight that flexibility in input can be helpful—but from a software design perspective, the primary goal is to reduce user errors and ensure data consistency, not just accommodate every possible way someone might want to write something.

For example, while "1 hr 30 min" and "1.5 hr" are both understandable, allowing too many variations increases the risk of parsing errors, misinterpretation, or edge-case bugs. It's often better to guide users toward structured input, such as:

A dedicated duration picker (like dropdowns for hours and minutes)

Input masks or formatting hints (e.g., hh:mm)

Auto-conversion after typing

This way, the system helps users enter valid data without ambiguity, while still offering a smooth experience. Flexibility is great—but clarity and reliability come first.