When developing applications and services, we generally tend to use the ISO 8601 standard. It's the most common way to represent a specific point in time and most programming languages and libraries work using them.

However, ISO 8601 is designed for timestamps, not intent. It demands total precision. When we try to represent events in data, we often don't have (or want) that level of detail.

For example, when an event is announced to be in "March 2026", an ISO string forces us to input a day and a time. Often we might either fill it with zeros as a placeholder or use the description field as our date indicator.

Depending on how an application was developed, this might lead to users seeing something like "March 1st at midnight", which is inaccurate. We should be able to display the date of an event correctly to the user.

What's worse is when we try to handle time zones with this approach, we might get into an even bigger problem. If the user is behind UTC time and we encode a timestamp such as 2026-03-01T00:00Z, they might see something like "February 28th 23:00", which is now even more inaccurate.

No one talks using UTC

When we are talking about events, we rarely care about the specific point in time about when it starts. If a concert starts at 19:00 in Brussels, everyone in Brussels is looking at their wall clock. When you tell a friend, "I'll be there in 2 PM", you aren't thinking in UTC; you're thinking in the local context of where the event is taking place.

So, to solve our problems when representing dates and times, we need a way to preserve the wall-clock time (the intended time at the location).

We should also be accommodating cases where users might not know the full precise time of an event. This means that the wall-clock time could be partial.

We should be able to show users when an event starts in their current timezone for accessibility and accuracy reasons. The location of some event might be close to a timezone boundary, which might introduce ambiguity. The user and the event might have differing time zones.

This means that we need a machine readable format for representing partial dates with timezone information.

The Partial Date Definition

A Partial Date is defined as a modified RFC 9557 string.

YYYY(-MM(-DD(THH:mm)?)?)?[TZ]

A Partial Date can have four levels of precision: year-only, year and month, a date, date and time. Each component must be in order which means that you cannot define a month without specifying a year.

Partial Dates must include an IANA timezone identifier wrapped in square brackets at the end. This allows us to convert partial dates between time zones easily. The components of a Partial Date are always in the timezone specified.

Examples:

  • 2026-03[America/Vancouver] - March in Vancouver

  • 2027-04-01T14:00[Europe/Vilnius] - 2 PM in Vilnius

  • 2030[Europe/Kyiv] - Year 2030

  • 2026-10-30[Asia/Tokyo] - October 30th in Tokyo

This way, we can represent events which have partial or missing information more accurately. If the user does not have enough information to fill it out, they don't have to.

This structure ensures we never have to "hallucinate" data. In traditional systems, when a day is unknown, developers often default to the first day of the month just to satisfy database constraints. In this format, if a component isn't in the string, it simply just doesn't exist. We prioritize being vague and correct over being precise and wrong.

Why not UTC offsets?

You might wonder why we require a full IANA timezone identifier (Europe/Vilnius) instead of an UTC offset (+02:00) like how it is in ISO 8601.

Offsets are snapshots; they don't account for the future. If an authority changes daylight saving rules between the time you announce an event and the day it happens, the data might become incorrect. By anchoring the date into a specific timezone identifier, we ensure that the wall-clock (or local time) remains accurate even if daylight rules change.

By moving away from rigid timestamps toward a model that respects intent, we can represent events with true structural integrity. This shift allows applications to be honest with their users, displaying only what is actually known rather than what a legacy format forces upon us.

However, time precision is only the first hurdle. This is just one of several fundamental oversights in how modern applications and services represent event information. In the coming few weeks, we'll be talking about the other "hidden" problems and how Open Evnt tries to solve them.

Stay tuned as we continue to XKCD 927 all over the place.