By Marc Alexander

The clocks go back on 25 October. If your GA4 property is set to London time, that Sunday has 25 hours, and every daily figure for it is a little odd. If it's set to something else, every day of the year is. Here's what the setting does, and where else a time zone hides.

What the property time zone decides.

Every GA4 property has one reporting time zone, set under Property details. It fixes where each day starts and ends in reports, for every visitor, wherever they are. A visitor in Manchester at 11pm and one in Sydney at 9am the next morning land in the same reporting hour.

Properties created from a UK Google account usually default to London, but not always. A property set up by an agency abroad, or copied from a template, can sit on Los Angeles or Central European time for years without anyone noticing.

The sign is a daily pattern that peaks at the wrong hour, and daily totals that never quite match orders by date in the shop platform.

The two odd days.

If the property is on Europe/London, GA4 handles British Summer Time itself. The cost is two irregular days a year:

  • Sunday 25 October 2026: the clocks go back at 2am, so the hour from 1am to 2am happens twice. The day has 25 hours, and hourly reports show two entries for that hour.
  • Sunday 28 March 2027: the clocks go forward and the day has 23 hours.

Neither is a fault. They matter only when someone compares those dates with the same dates in another year, or builds an hourly dashboard that assumes 24 rows a day. A note in the report is enough.

Choosing GMT instead of London avoids the irregular days, at the price of every summer day starting at 1am on the clock. For most UK businesses the London setting is the better trade.

Changing it.

A change applies from the moment it's saved and isn't applied to past data. On the day of the change, reports show either a short flat spot or a doubled hour, depending on the direction. Pick a quiet day, write down the date, and expect that day's figures to be off.

Other places a time zone hides.

  1. Google Ads. The Ads account has its own time zone. If it differs from the GA4 property, conversions imported from GA4 fall on different days in the two tools, and the daily figures never agree.
  2. The shop platform. Shopify, WooCommerce and the rest report orders by their own store time. A mismatch with GA4 moves late-evening orders across the date line.
  3. BigQuery. In the GA4 export, the event timestamp is UTC and the event date follows the property's time zone. Queries that build their own days from the timestamp drift by an hour in summer.
  4. Looker Studio and other dashboards. They show what GA4 gives them, but a blended source with its own setting can put the same sale on two dates.
  5. Server logs and the CRM. Usually UTC. Reconciling leads by day needs the offset applied.

UK businesses with customers elsewhere.

A property has one time zone, so a UK business selling to the US or Australia reports those customers' purchases on UK days. That's fine as long as everyone knows. Where regional teams need their own day boundaries, a separate property per market, or a BigQuery view that converts the timestamp per region, does it properly.

What to check.

  1. Open Property details and confirm the time zone and currency.
  2. Check the Google Ads account's time zone matches.
  3. Compare a week of GA4 purchases by date with the shop platform's orders by date.
  4. If you use the BigQuery export, check which field your queries use for the day.
  5. Put 25 October and 28 March in the reporting calendar as irregular days.

The setting is one of the checks in the GA4 mini audit, alongside the ones that cause bigger gaps: Direct traffic, duplicate conversions and revenue that doesn't match the shop. Marc Alexander is a GA4 consultant in London.