Limits of WooCommerce timezone handling for order timestamps across regions

Short answer

WooCommerce's timezone support is a single store-wide display setting, and that is a hard limit: there is no supported per-user or per-customer timezone display without custom code. On modern WooCommerce (3.x and later), order timestamps are stored in UTC and converted to the store timezone only at render time, so integrations that read the UTC fields are safe — but nothing guarantees that every field, plugin, or code path respects the conversion. You must normalize explicitly at your integration boundary.

Per-customer timezone display

There is no setting, filter, or API parameter in WooCommerce or WordPress core that renders order dates in a visitor's local timezone. The value under Settings > General (the WordPress timezone string) is one value per site, applied globally by wc_format_date() and the underlying date_i18n() machinery. If you need customers to see "their" time — for delivery windows or event bookings, for example — the realistic options are:

• Render dates in UTC or store time with an explicit label ("All times shown in GMT+1"), which removes ambiguity entirely.
• Convert client-side: output a UTC timestamp and localize it with JavaScript's Date handling in the browser.
• Write custom code keyed to a customer profile field — feasible, but you own the maintenance.

What is actually stored

On WooCommerce 3.x+, order dates are stored in UTC. In the classic post-based storage this is the post_date_gmt column; in the newer HPOS tables it is the date_created_gmt / date_paid_gmt style columns. The non-GMT counterparts (post_date, date_created_local) are site-local values derived using the current store timezone. The REST API exposes both: date_created (site-local) and date_created_gmt (UTC).

So there is no blanket "guarantee" — there are two parallel representations, and which one a third party receives depends on which field you hand it. The safe rule: always integrate on the _gmt fields, and if you receive a non-GMT field from an external source, treat it as unnormalized until you confirm its offset.

The correct conversion boundary

When rendering dates outside standard templates, wc_format_date() is the documented boundary — it takes a stored timestamp and applies the site's configured timezone and date format. Two known cases silently bypass it:

• Raw PHP date functions. date(), time(), and strtotime() in custom templates reflect the PHP/server default timezone, not the WordPress setting. WordPress deliberately sets PHP's default to UTC at runtime, so date() output is UTC regardless of the store setting — a classic source of "times are off by N hours" bugs.
• Plugin-written meta. Third-party plugins frequently store their own date meta in arbitrary formats and timezones. WooCommerce makes no guarantee about those fields; audit any plugin whose dates you consume.

Version caveat and the timezone-change trap

These claims assume WooCommerce 3.x or later. Pre-3.0 releases stored some dates as site-local values without _gmt counterparts, so verify the version before assuming UTC storage. Also note: changing the store timezone after orders exist does not alter stored UTC values, but every site-local field is recomputed at read time — an integration that consumed date_created before the change will see an apparent shift afterward.

Verify on your install

1. Pick a known order and compare its local vs GMT columns (post_date vs post_date_gmt, or the HPOS equivalents) — the difference should equal your configured offset.
2. Fetch the order via the REST API and confirm date_created_gmt matches the database UTC value.
3. In a test snippet, render a known UTC timestamp with wc_format_date() and confirm it matches the store timezone.
4. Grep active plugins and theme code for direct date( or strtotime( calls on order data.

If your store is on a version older than 3.0, or if a critical integration only receives site-local fields, say which — that changes the recommendation from "use the _gmt fields" to "normalize before export."