Why PHP Booking Features Fail

A booking feature is not only an insert form. Several systems must agree about what the selected value means. The browser sends a date string. PHP parses that string in a timezone. The application checks whether it is allowed. MySQL stores it using a temporal column. A conflict query decides whether the resource is already occupied. Finally, the page converts the stored value back into a time that a user can understand.

A visible symptom such as “wrong appointment time” does not identify the failing stage. The browser may send a timezone-free local value. PHP may interpret it using the hosting server’s default timezone. The application may convert it to UTC twice. MySQL may convert a TIMESTAMP according to its session timezone. The final page may then convert it again.

Validate Dates Exactly Instead of Only Parsing Them

A parser may accept and normalize an impossible value rather than rejecting it. For example, a day beyond the end of a month can be moved into the next month. This behavior is useful for date arithmetic, but it is usually wrong for form validation.

A strict validation helper should perform three checks:

1. The value can be parsed using the expected format.
2. The parser produced no warnings or errors.
3. Formatting the parsed object returns the original value.

$date = DateTimeImmutable::createFromFormat(
    "!Y-m-d",
    $submittedDate,
    $timezone
);

$errors = DateTimeImmutable::getLastErrors();

$hasErrors =
    $errors !== false &&
    (
        $errors["warning_count"] > 0 ||
        $errors["error_count"] > 0
    );

$isExact =
    $date !== false &&
    !$hasErrors &&
    $date->format("Y-m-d") === $submittedDate;

A regular expression can verify the shape of a value, but it cannot prove that February 30 is a real date. A browser’s HTML validation improves the user interface, but the server must still validate the submitted value because HTTP requests can be created without the form.

HTML Date Inputs Send Standardized Values

The appearance of an HTML date picker depends on the user’s browser and locale, but its submitted value uses YYYY-MM-DD. A datetime-local field normally submits YYYY-MM-DDTHH:mm.

The word “local” is important. The datetime-local value identifies a calendar date and wall-clock time, but it does not include an IANA timezone or UTC offset. PHP cannot know whether 2026-07-30T10:00 means Toronto, Kathmandu, London or another place unless the application supplies that rule separately.

A booking form serving several regions should submit or derive an explicit timezone identifier. A clinic operating only in one city can use one application-configured timezone, but it should still set that timezone deliberately instead of inheriting an unknown server default.

DATE, DATETIME and TIMESTAMP Are Not Interchangeable

A calendar-only value should normally remain a date. An international online meeting represents one exact instant and is commonly converted to UTC. A recurring doctor schedule such as “every Monday at 9:00 AM Toronto time” is a local wall-clock rule and should preserve its timezone identity rather than being reduced to one permanent offset.

Use an Explicit Timezone Strategy

Choose one meaning before writing conversion code:

• Calendar date: store a DATE and do not perform UTC conversion.
• Global instant: interpret the submitted local value in its source timezone, convert once to UTC and store the UTC value.
• Local schedule rule: store the local date/time or recurring rule together with an IANA timezone identifier.

A fixed UTC offset such as -04:00 is not equivalent to an IANA zone such as America/Toronto. The IANA zone contains historical and future daylight-saving rules. The offset only describes one moment.

Exact Duplicate Slots and Overlapping Ranges Are Different

A fixed-slot project may define appointments only at 9:00, 9:30 and 10:00. In that design, preventing two bookings for the same resource and exact slot can be enforced with a composite UNIQUE constraint or a unique slot identifier.

UNIQUE KEY uq_resource_slot (
    resource_id,
    start_at
)

A variable-range reservation is different. One booking from 10:00 to 11:00 conflicts with another booking from 10:30 to 11:30 even though neither start time nor end time is equal.

Two half-open ranges overlap when the existing start is before the new end and the existing end is after the new start:

existing_start < new_end
AND existing_end > new_start

With this rule, a reservation ending exactly at 11:00 does not conflict with another beginning at 11:00. Change that policy only when the project requires cleanup or preparation time between bookings.

A Pre-Check Alone Does Not Prevent Simultaneous Double Booking

This sequence is vulnerable:

1. Request A checks the slot and sees it is free.
2. Request B checks the same slot and also sees it is free.
3. Request A inserts the booking.
4. Request B inserts the second booking.

Both requests made a correct observation, but neither observation was protected until the insert.

For discrete bookable slots, a strong student-project design creates one row per slot, locks that row with SELECT ... FOR UPDATE inside a transaction and gives the appointment table a UNIQUE constraint on the slot ID. The database remains the final guard even if two browser requests arrive almost simultaneously.

Variable ranges are more complex because a simple UNIQUE index cannot express every possible overlap. A project can use a carefully indexed overlap check inside a suitable transaction, but pre-created slot rows are often easier to reason about, test and explain in a student viva.

Cancelled Bookings Should Follow a Defined Availability Policy

A conflict query that checks every appointment row may keep cancelled appointments blocked forever. Most systems should consider only active states such as pending and confirmed:

WHERE status IN ("pending", "confirmed")

Deleting cancelled rows can free the slot, but it removes useful history. Keeping a cancelled status normally gives better audit and reporting information. The conflict query must then exclude that status deliberately.

Rescheduling should be treated as one controlled operation. Validate the new time, check its availability, update the booking and preserve the previous information in a log when the project requires history.

Why Today’s Appointments Can Disappear

“Today” depends on a timezone. At one instant, the calendar date in Toronto can differ from the date in Kathmandu or UTC. A PHP page that calculates today in one timezone while MySQL evaluates CURDATE() in another can select different ranges.

Calculate the intended day boundaries in the application timezone, convert the boundaries to the storage timezone and query a half-open range:

WHERE start_at >= :day_start
  AND start_at < :next_day

This is usually clearer than applying DATE(start_at) to every stored row. It also avoids ambiguous inclusion of 23:59:59 and fractional seconds.

Past and Future Checks Must Compare Compatible Objects

Do not compare a submitted date string with a differently formatted current-time string. Parse both into date objects that share an explicit timezone.

A date-only rule such as “today or later” should compare calendar dates at midnight in the intended local timezone. An exact appointment rule such as “at least 30 minutes from now” should compare complete instants.

The difference matters near midnight. A booking for later today should not be rejected merely because a date-only value was interpreted at midnight and compared with the current afternoon time.

Daylight-Saving Time Needs a Product Rule

Some timezones skip a local hour when clocks move forward and repeat a local hour when clocks move backward. A datetime-local control can represent a wall-clock value without proving that the moment is unique in the selected timezone.

Applications that schedule events across daylight-saving transitions should:

• Store an IANA timezone identifier.
• Validate the local value in that timezone.
• Decide how to handle a missing local time.
• Decide which offset applies when a local time occurs twice.
• Store the final UTC instant and original timezone when an exact appointment has been confirmed.

Most small college projects do not need a complex timezone interface, but they should at least avoid silently relying on whichever timezone the hosting server happens to use.

Safe Date and Booking Debugging Order

1. Print the exact raw submitted start and end strings.
2. Confirm the form input type and expected server format.
3. Set the application timezone explicitly.
4. Parse the value exactly and inspect warnings.
5. Verify the start, end, duration and past-date rules.
6. Define whether the value is a date, local schedule or instant.
7. Confirm the matching MySQL column type and storage timezone.
8. Run the conflict query with known bookings.
9. Add the final database uniqueness or slot-lock guard.
10. Test two simultaneous requests for the same resource.
11. Query a full day using explicit start and next-day boundaries.
12. Convert the stored value once for display.

Common Fixes That Create New Date Bugs

Continue Your CodeZips Project Workflow

Technical References

• PHP Manual: DateTimeImmutable::createFromFormat()
• PHP Manual: DateTimeImmutable
• PHP Manual: DateTimeZone
• MDN: HTML Date Input
• MDN: HTML datetime-local Input
• MySQL Manual: Date and Time Data Types
• MySQL Manual: DATE, DATETIME and TIMESTAMP
• MySQL Manual: CREATE TABLE and UNIQUE Constraints
• MySQL Manual: InnoDB Locking Reads