App Dates Without Missed Appointments
Show every appointment in the time zone where it happens, label that zone in the interface, and require the user to confirm the zone before saving. This prevents the common failure where a device set to one region silently shifts an event that belongs to another.
Event zone first, device zone second
Store the event's own time zone with the appointment record, not only a UTC timestamp. A booking made for a clinic in Beirut should carry the zone identifier for Beirut, so the displayed hour stays correct no matter where the user opens the app later. The device zone is useful for context, but it should never overwrite the event zone.
When the two differ, show both. A line such as 09:00 Beirut time, 07:00 your local time gives the user enough information to act. If the app shows only the converted local time, a traveler can arrive at the wrong hour without any warning.
Make confirmation explicit
Before saving, present the zone and the full date in words. Ask the user to confirm the zone rather than assuming the device setting is correct. A short confirmation step catches the case where someone books for a relative in another country while sitting in a different one.
For recurring appointments, confirm the zone once and display it on every occurrence. If the user changes the device zone, do not silently move existing events. Offer a prompt that explains the change and lets the user decide.
Daylight saving and month boundaries
Daylight saving transitions can shift a stored local time by an hour. Keep the zone identifier and the local wall time, then recalculate the offset when displaying. Test the days around known transitions in the zones your users actually use.
Month boundaries matter for reports and reminders. An appointment on the last day of a month in one zone can fall in the next month in another. Decide which zone governs monthly grouping and state it in the interface. For Arabic display, confirm whether the user expects Gregorian or Hijri dates, and label the calendar you show rather than mixing them.
Ambiguous numeric dates and Arabic display
A date written as 03/04/2025 means different days in different regions. Use a written month or an explicit format label. In Arabic interfaces, ensure the date order and the numerals match the rest of the layout, and keep right-to-left text from reversing the sequence of day, month, and year.
Suppose a clinic in Amman books a patient who lives in Dubai. The app stores the Amman zone, shows 14:00 Amman time and 15:00 Dubai time, and asks the patient to confirm which zone the reminder should use.
A practical acceptance test
Set a device to one zone, create an appointment in a second zone, then change the device to a third zone and reopen the app. The appointment must still show the original event zone and the correct local hour. If the displayed time moves with the device, the implementation fails.
Repeat the test across a daylight saving boundary and across a month end. Check that reminders fire at the intended event time and that the Arabic layout keeps the date readable. These checks are cheap to run and catch the errors users notice most.
Continue reading
A practical next step
Explore the related Devign work, then discuss your requirements before committing to a project scope.