Developers often treat a date as a single instant, but it is a local date—a calendar day that slides across the globe. A global instant exists only when a time and a timezone are attached. Misreading this distinction fuels bugs in scheduling, billing, and compliance for production systems daily.

Take Christmas or New Year: in Sydney it starts hours before London, while New York celebrates later. A deadline written as “by June 5th” becomes a 24‑hour window, not a fixed point. Storing it as UTC midnight misaligns users, causing rejections and lost trust for global teams and customers everywhere daily.

To avoid these pitfalls, ask whether a requirement is a calendar concept or a physical moment. If it lacks a time or timezone, treat it as a local date and never convert it to UTC blindly. The next post will map the seven time types developers must master for future.