Dates and timezones

The rule

A next-opening date is a date, not a timestamp. It describes the freelancer’s availability, and it carries no time of day because it never had one.

So it is served the same to every reader, wherever they are. If a freelancer in Colombo is free from 12 March, the page says 12 March to somebody in Los Angeles too - because 12 March is the day they are free.

Why converting it would be wrong

A conversion needs an instant, and there is no instant here. To convert the date, you would first have to invent a time of day for it - midnight? 09:00? - and then shift it. A reader far enough west would be shown 11 March: a date on which the freelancer is not free.

The conversion manufactures a falsehood out of a fact that had no ambiguity in it. A bare calendar date has no offset, so there is nothing to correct.

Two alternatives were considered and rejected, for the record:

• Rendering it in the owner’s zone and naming the zone - “12 Mar 2026 (Asia/Colombo)”. Naming a zone on a value with no time of day invites the reader to think a conversion is needed, which is the confusion this exists to remove. It also puts the freelancer’s approximate location on a public page.
• Converting in the browser. Wrong for the reason above, and it would need client-side script on a page designed not to have any.

What the markup gives you

What was genuinely ambiguous is the value to a machine: the date used to be bare text, so anything parsing it had to guess at the format. The visible text is unchanged and the exact value sits beside it:

Next opening: <time datetime="2026-09-03">3 Sep 2026</time>

• The datetime attribute is a bare calendar date - YYYY-MM-DD, with no time and no offset. That is the HTML form for a date with no time of day, which is precisely what this value is.
• Read that attribute, not the text. It is exact and it is stable. The visible wording is for people.
• The <time> wraps the date only, not the whole line, so the label and the value are separable.
• The element is absent when there is no date. “Available now” and the fully-booked sentence name no date, so wrapping them would claim a precision they do not have. Do not expect a <time> in those cases - expect plain text.

The same markup appears on the Beacon page, in the badge document and in the freelancer’s own view, because one function produces all three. They cannot disagree.

Do not reformat it into an all-numeric date

The visible form is deliberately “3 Sep 2026” and never “03/09/2026”. The audience for a Beacon is strangers, and an all-numeric date is read as two different days in two different countries - which is the exact ambiguity the long form exists to avoid.

If you are rendering the date yourself, parse the datetime attribute and format it unambiguously. Do not run it through a locale-aware date formatter with a timezone attached: that is the conversion described above, arriving through a library.

The one date that does carry a time

The freshness marker - “updated 2 hours ago” - is about an instant rather than a calendar day, so it does carry a full timestamp in its own <time> element. It is truncated to the hour before it leaves the server, deliberately: a minute-precise public timestamp would publish when a freelancer works, including at odd hours.

So it is exact to the hour and no finer, and there is no finer value to be had.

The same rule, for the freelancer

What “next opening” means describes the same decision from the other side, along with how the date is worked out in the first place.