An order placed at 3:40 in the afternoon showing a “Date created” of 9:40 in the morning is the kind of bug that erodes trust in a system fast — not because it breaks anything functionally, but because every timestamp on every screen becomes something staff have to mentally correct.
Finding the actual offset
The gap was a consistent six hours, which is exactly the difference between UTC and Bangladesh Standard Time (UTC+6) — a strong hint before even opening the settings screen. WordPress’s site timezone was set to UTC instead of Asia/Dhaka, meaning every timestamp the platform generated or displayed was technically correct in UTC and wrong for anyone reading it locally.
One setting, but a question worth asking first
The fix itself was a single change under Settings → General. The more useful question was whether it would need to be paired with a data migration — would existing orders need their stored timestamps rewritten too? The answer, in WooCommerce’s case, is no: order timestamps are stored in UTC internally and converted to the site’s configured timezone at render time, every time a page loads. Correcting the site setting instantly corrected the displayed time for every existing order retroactively, with nothing in the database needing to change.
Key takeaways
- A consistent, fixed-hour timestamp offset almost always points to a timezone misconfiguration rather than a code bug — check the gap against known UTC offsets first.
- Understanding whether a platform stores data in UTC-and-converts-at-render, versus storing pre-converted local time, tells you immediately whether a settings fix alone is enough.
- The smallest fixes are sometimes the ones worth writing up — a one-line settings change with genuine, retroactive, store-wide impact.
Running into a similar limitation in your own WooCommerce or WordPress admin? Let’s Talk — Artintech Solution builds exactly this kind of custom store tooling.