Store Timestamps in UTC and Display Them in Local Time

A CRM entry showing only '10:30' can be misread by staff in different timezones because it does not indicate which zone it represents. The article distinguishes between instants, such as an enquiry acceptance time, which should be stored in UTC or a timezone-aware type, and local scheduling intentions, which need a local date, time, and IANA timezone identifier. It recommends converting instants to a documented display timezone with a locale-aware formatter and labeling the zone where confusion is possible. Recurring schedules must preserve timezone rules because fixed UTC offsets fail to account for daylight-saving changes, and ambiguous or nonexistent local times should be handled by a documented policy. The author also advises keeping event occurrence, receipt, and next-attempt times as separate fields and testing edge cases such as daylight-saving transitions and invalid dates.