Canonical page: https://tellenze.com/blog/a-deadline-needs-a-time-zone # A Deadline Needs a Time Zone ![Two unnumbered clock faces showing different times are linked by a teal cord on an ivory background.](https://tellenze.com/blog/a-deadline-needs-a-time-zone/cover/01m4ntawnnzzn37kw1eyjgzz3j) A planning day, a shared cutoff and a weekly local time make different promises. A fictional film festival shows why a date field needs to know which one it holds. Imagine a small film festival in Amsterdam. Its coordinator, Evi, is sending the programme to the printer at seven on Friday evening. Daniel, a contributor in New York, opens the submission form just after two in the afternoon and finds it closed. The message he saved says “Changes due Friday”. As far as he's concerned, Friday is still going rather well. He hasn't even finished lunch. This is a fictional festival, but the disagreement is easy to recognize. Evi meant a closing moment. Daniel read a day. The application collected one date and quietly made the rest of the decision. Before choosing how to store a deadline, it's worth finding out which of those promises the product is making. ## A day can stay a day The festival also has a planning board. One card says that the programme should be ready on 30 October. It's a note about the day's work, rather than a control that shuts a form. That date doesn't need to become midnight somewhere merely to fit a timestamp field. Adding a time would give it a precision the team hasn't agreed on. Converting that invented midnight for another reader could then display the previous date. A birthday makes the distinction familiar. The named day is part of the fact being recorded; there needn't be one worldwide instant at which it begins. [MDN's description of Temporal.PlainDate](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/PlainDate) gives this meaning a concrete technical shape: a calendar date without a time or time zone. The page currently marks limited browser availability, so it's an example of a useful distinction, not a recommendation to assume the API works everywhere. For a planning card, a date can be enough. The interface might make that intention clearer by calling it a target day. It should also leave people room to ask what “ready” means. The trouble starts when that same modest value acquires a less modest job. If it ends submissions, expires access or triggers a message, someone has to decide when that happens. ## Pick the closing moment At our festival, the printer needs the programme at 19:00 Amsterdam time on Friday, 30 October 2026. The submission cutoff could be earlier, but let's suppose Evi has deliberately chosen 19:00 for this illustration. Under the time-zone rules checked for that date, that is 18:00 UTC and 14:00 in New York. Daniel's form closing just after two is consistent with Evi's choice. The short message failed to explain the choice to him. A useful submission page could show the full date and the Amsterdam cutoff, together with the equivalent in Daniel's selected time zone. The conversion changes the reading on the clock; it preserves the closing moment. That is different from offering every contributor until the end of their own Friday. Such a policy could be reasonable, too. It would create different closing moments, and Evi would need to plan the printing around them. A product should choose that deliberately. The [W3C's Working with Time and Timezones guidance](https://www.w3.org/TR/timezone/) distinguishes ways of representing time and discusses how they interact with a person's local expectations. It's a Group Draft Note, rather than a normative Recommendation. The useful design question it brings into view is which meaning should survive a conversion. Here, Daniel travelling to another city should change the displayed local equivalent, not quietly extend the shared cutoff. Conversely, changing a harmless planning date into an access deadline would be a change to the product's behavior, even if the field still looks identical. There is no database type that can make that decision for Evi. ## Thursday at nine should stay Thursday at nine The festival team reviews submissions every Thursday at 09:00 in Amsterdam. Evi wants the meeting to fit the local working morning. On 22 October 2026, that start is 07:00 UTC. On 29 October, after Amsterdam's seasonal clock change, it is 08:00 UTC. Both are Thursday at nine for Evi. Taking the first UTC start and adding exactly 168 hours would produce 08:00 Amsterdam time for the second meeting. The arithmetic would be consistent. The appointment would be wrong. The [iCalendar specification's recurrence guidance, RFC 5545](https://www.rfc-editor.org/rfc/rfc5545.html#section-3.8.5.3), recommends a local start with a time-zone reference for this kind of recurring event, so occurrences can keep their local start time across zone changes. It describes a calendar format's behavior, not a promise about every scheduler. That gives the team a practical distinction. “Every Thursday at nine in Amsterdam” needs the local rule and its zone. “Run again after 168 hours” describes an elapsed interval. Either can be useful; they serve different purposes. Daniel's clock may still show a different local meeting time after a seasonal change. Keeping Evi's local morning fixed doesn't keep everyone's local morning fixed. The invitation can make the anchor visible and show the coming occurrences. Some local clock readings also repeat or disappear during seasonal transitions. A product scheduling work in those hours needs an explicit way to resolve that case. A named zone helps compute the possibilities; it doesn't tell the designer which choice the person intended. ## Today's offset isn't the whole rule It's tempting to save Amsterdam as `UTC+02:00` after looking at a summer clock. That offset is accurate for particular dates, but it doesn't describe the city's whole year. An IANA zone identifier such as `Europe/Amsterdam` connects the local time to a set of rules. Even those rules can change. [IANA's Time Zone Database overview](https://www.iana.org/time-zones) explains that its data is updated for changes to boundaries, offsets and daylight-saving rules. Its [account of the database's scope and limits](https://data.iana.org/time-zones/tzdb/theory.html) also warns that future conversions are predictions: later government decisions can make an earlier conversion wrong. This matters when deciding what a future booking promises. If a workshop promises nine in the local morning, changed rules may require a different UTC instant. If an announced cutoff promises one fixed instant, moving it automatically could break that promise. Keep enough information to distinguish those intentions, and decide how affected future events should be handled. This is an engineering and product choice; our fictional festival isn't evidence that one policy suits every service. ## Read the field as the person filling it in Try one real date field with two people in different time zones. Let each explain what happens when that date arrives, before showing them the storage format. Then follow one consequence. Does a form close? Does a reminder appear? Does a card merely become a little more urgent? If the value repeats, compare an occurrence on either side of a clock change. Check the wording alongside the behavior. A local equivalent needs a visible zone and date. A recurring meeting needs an anchor people can understand. A planning note may need neither a countdown nor a closing hour. You may discover the field is only a target for the day's work. Leave it as a day. If it closes access, put the cutoff where the person about to lose access can see it. ## Further reading - [Working with Time and Timezones — W3C](https://www.w3.org/TR/timezone/) — draft guidance on representations, local expectations and future events. - [Temporal.PlainDate — MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/PlainDate) — a concrete calendar-date model, with current browser-support limits. - [Internet Calendaring and Scheduling Core Object Specification, section 3.8.5.3 — RFC 5545](https://www.rfc-editor.org/rfc/rfc5545.html#section-3.8.5.3) — recurring local times and their zone references. - [Time Zones — IANA](https://www.iana.org/time-zones) — why time-zone data needs updates; the linked theory document explains limits to future predictions.