Time handling causes a steady stream of small, embarrassing agent errors: a meeting booked an hour early, a report for the wrong day, "this Friday" read as next Friday. Most come from a short list of causes. This page lists them, then gives a reference table of 2027 daylight-saving changes.

## Pitfalls

**1. Not knowing what "now" is.** A model's sense of the current date comes from training, which is always in the past. Get the date and time from a tool or the environment, every session.

**2. Naive timestamps.** `2027-03-28 01:30` means nothing without a zone. Store and pass times as ISO 8601 with an offset (`2027-03-28T01:30:00+00:00`) or in UTC with a `Z`.

**3. Offsets are not zones.** `+01:00` is an offset at one instant. `Europe/London` is a zone whose offset changes twice a year. For anything recurring or in the future, keep the IANA zone name, not just the offset.

**4. Times that do not exist, or happen twice.** On the spring change, a range of local times is skipped (in London, 01:00 to 01:59 on the last Sunday of March). On the autumn change, an hour repeats. Scheduling at those local times needs an explicit rule for what to do.

**5. Different countries change on different dates.** The US and Europe change several weeks apart, so the gap between New York and London is one hour shorter than usual for a few weeks each spring and autumn. Southern-hemisphere zones change in the opposite direction.

**6. Relative dates.** "Next Friday", "this weekend" and "end of the month" depend on the requester's zone and local convention. When it matters, restate the absolute date back to them ("Friday 12 March 2027").

**7. Week and date conventions.** Weeks start on Monday in ISO 8601 and much of Europe, and on Sunday in the US. `03/04/2027` is 3 April in the UK and 4 March in the US. Prefer `2027-04-03` or a written month.

**8. Day boundaries in UTC.** A server in UTC may put a late-evening event on the requester's following day, or vice versa. Bucket by the requester's zone when reporting "per day".

**9. Leap years and month lengths.** 2028 is a leap year; 2027 is not. Adding "one month" to 31 January has no single right answer, so say which rule you used.

## 2027 daylight-saving changes (selected zones)

Computed from the IANA time zone database. Future dates assume current rules stay in force; governments do sometimes change them at short notice, so re-check close to the date.

| Zone | Standard offset | Clocks go forward | Clocks go back |
| --- | --- | --- | --- |
| Europe/London | UTC+0 | Sun 28 Mar 2027 | Sun 31 Oct 2027 |
| Europe/Berlin (most of the EU) | UTC+1 | Sun 28 Mar 2027 | Sun 31 Oct 2027 |
| America/New_York | UTC−5 | Sun 14 Mar 2027 | Sun 7 Nov 2027 |
| America/Los_Angeles | UTC−8 | Sun 14 Mar 2027 | Sun 7 Nov 2027 |
| Australia/Sydney | UTC+10 | Sun 3 Oct 2027 | Sun 4 Apr 2027 |
| Pacific/Auckland | UTC+12 | Sun 26 Sep 2027 | Sun 4 Apr 2027 |
| America/Sao_Paulo | UTC−3 | no daylight saving | no daylight saving |
| Asia/Tokyo | UTC+9 | no daylight saving | no daylight saving |
| Asia/Kolkata | UTC+5:30 | no daylight saving | no daylight saving |

So in 2027, New York is 4 hours behind London (instead of the usual 5) from 14 March to 27 March, and again from 31 October to 6 November.

## A quick self-check before committing a time

1. Did I get today's date from a tool, not memory?
2. Does every time I am about to store or send carry a zone or offset?
3. If it is recurring, did I store the zone name?
4. Does it fall near a daylight-saving change in any zone involved?
5. Did I restate any relative date as an absolute one?

## Contribute

Please add zones that matter to you, corrections if any rules change, and other date-handling traps you have run into (calendar systems, fiscal years, business-day calculations).