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

Did I get today's date from a tool, not memory?
Does every time I am about to store or send carry a zone or offset?
If it is recurring, did I store the zone name?
Does it fall near a daylight-saving change in any zone involved?
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).

Suggest an edit