Timestamp format and Time Zones Completely Undocumented for both REST and GraphQL APIs

Highlighted
New Member
2 0 2

Besides some random community post answers, I cannot find ANY documentation on the behavior of the Shopify Query Language filter paramters for TIME ZONES, nor can I find (anywhere!!!) information about proper standard/format of the time fields.  Depending on the format of the timestamp I pass the to the API, I get wildly different query results in both the REST and GraphQL APIs.

PLEASE make available the preferred way of dealing with time in the APIs and Shopify Query Language.

0 Likes
Shopify Partner
1178 1 62

If you look at something that accepts a date filter (e.g. https://help.shopify.com/en/api/reference/orders/order#index) you'll notice they provide the format in the example: 2014-04-25T16:15:47-04:00

 

This is the ISO 8601 format, which includes a timezone offset. Personally I always send query parameters in UTC so that would be something like 2019-06-22T11:05:00Z

 

HTH, Gavin.

 

 

Take a look at our Apps: www.bookthatapp.com ♥ www.searchifyapp.com ♥ www.productsassistant.com
0 Likes
New Member
2 0 2

Thanks for the quick relpy, Gavin. I either did not look at or did not notice this in the REST documentation (was primarily working in GraphQL).  

 

Here’s some questions for the API/documentation team though:

 

  • Why is this not documented on the GraphQL side? Or in the Query Language docs? 
    • Think about it: the REST order endpoint params are not exactly the same concept as the Query Language. Why should I know that’s the spec for the other thing(s)? For example the parameter names are certainly not even the same ("created_at" and "created_at_min"  versus "createdAt" and "created_at:>..." (QL))
  • Why is this field not validated anywhere? Why does passing non-ISO formatted timestamps not raise exceptions? What’s the point of using ISO then?
  • Note if I pass a non-ISO8601 timestamp like this I still get results: “2019-06-21+20:37:35+-0400” 
    • Here's some different results I get from different values (in Ruby):
                   Timestamp               GraphQL   Gem/REST  
       ---------------------------------- --------- ---------- 
        Fri, 21 Jun 2019 11:26:23 -0400          3         66  
        2019-06-21 15:26:23 UTC                  0         66  
        "2019-06-21T11:26:23-04:00"              3         66  
        "2019-06-21T15:26:23Z"                  85         66  
  • What about the other undocumented thing from the community answers where requests supposedly have to be formatted with the same time zones as the store is set to? (Ie, it doesn’t convert back and forth from UTC times? Again, why use ISO8601 at all?).
  • Note that using the -04:00 offset as you suggested does not actually work (!?), even though the store in question should be set to Eastern Time... which is currently at -04:00 if observing DST, as New York does.... But then the API tells me the store is set to this:
    "timezone"=>"(GMT-05:00) America/New_York",
    "iana_timezone"=>"America/New_York",
    (I mean...: lol) -- The API itself suggests the wrong offset? https://www.timeanddate.com/time/gmt-utc-time.html
  • Why not just SAY it’s ISO somewhere? The current doc relies on a persons’ ability to recognize it by syntax/convention alone.

This is just bananas. With my dev environment in EDT (UTC-0400,) Store in GMT-0500 according to API (?), our production server in UTC, AND the API not even doing offsets correctly AND loosely accepting all different formats, it is basically impossible to write good queries without better documentation.

 

 

2 Likes
Tourist
5 0 2

What about the other undocumented thing from the community answers where requests supposedly have to be formatted with the same time zones as the store is set to? (Ie, it doesn’t convert back and forth from UTC times? Again, why use ISO8601 at all?).

 

Thank you for posting this, Stephen, I thought I was going crazy.

It seems that the offset is simply ignored and all date times have to be formatted with the same time zone as the store.

 

I don't even want to know what happens if the store owner changes the shop's time zone ....

 

 

 

 

1 Like