Timezones are a confusing topic for a global marketplace like Amazon. For example, a customer in New York places an order on March 11, 2024, at 1 AM (EST), but it is March 10, 2024, at 10 PM (PST) @ Amazon HQ in Seattle. When did the order occur? March 11th or March 10th? What if I said both are accurate?
Let's dig into this a little more.
Amazon's Use of Coordinated Universal Time (UTC)
Amazon uses Coordinated Universal Time (UTC) for its underlying data systems. This approach ensures consistency across global operations but can lead to confusion when viewing data in different interfaces.
Per Amazon:
“Amazon formats date and time-related data similar to the RFC 3339 standard, which defines a subset profile of ISO 8601 for use in Internet protocols and standards. This section will clarify how to format and use date and time data in Amazon.”
Timezone Differences: An Example
To illustrate how timezone differences can affect data interpretation, consider the following example:
Two sales charts for the same Amazon Seller in the US market on September 16, 2024:
Top chart: $25,400 in sales and 3,000 units at 11 AM
Bottom chart: $13,018 in sales and 1,216 units at 11 AM
How can both of these be accurate? The underlying data is supplied and stored using UTC. The bottom chart reflects a visual using the raw UTC timezone. However, the top chart "time shifts" the data from UTC to EDT. As such, they are both technically accurate but convey very different outcomes depending on the timezone you want to use for an analysis.
User Interfaces Determine Display Logic
So, where does a chunk of the confusion arise? Typically, it is how a UI decides to display the data, as we have shown above.
For most in NA, the Seller Central interface displays information in the Pacific timezone (PST). However, as stated, Amazon provides data from its systems using UTC. The UI, or report, is time-shifting from UTC to PST based on the requirements of the UI.
Let's dig into another example. Let's say you have a transaction with an order date of 2024-03-16T06:32:16.50 (March 16th, 2024, 6:32 AM UTC) in the data. Amazon then displays this time in the Seller Central interface as 2024-03-15T23:32:16.50 (March 15, 2024, 11:32 PM PST).
Coordinated Universal Time is 8 hours ahead of Pacific Standard Time or 7 hours ahead of Pacific Daylight Time. Both transaction timestamps are correct, except one is based (UTC), and the other is derived (PST). What do we mean by derived? This means that you can convert the UTC timestamp to any other timezone. Amazon uses PST for display in North America but will shift to CET in Europe.
As a result, how an interface decides to display data can significantly shift end-user perceptions of the timing of orders, returns, and fulfillment, as shown in our 11 AM example above.
Why does Amazon use UTC?
Why use UTC? It is the most flexible, consistent approach to dealing with time zones. Per the RFC 3339 spec;
Because the daylight saving rules for local time zones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC). This specification does not cater to local time zone rules.
UTC avoids local, regional, or national variations for time zones, including daylight savings time (DST). This is why a timestamp should always be converted when displayed.
The Seller Central UI converts UTC to display it as PST, CET... and most data analytics tools, such as Tableau, Looker, DataStudio, and Quicksight…allow you to convert a timestamp from UTC to EST, EDT, PDT, PST, or your preference. Shifting a timezone is simple enough once you know it needs to happen.
Impact on Data Interpretation
Remember that Amazon systems' UTC default is stored exactly as they provide it in your data lake or warehouse. Understanding timezones may help you explain why an order may have one date in one place and different data in another.