Inconsistent Orders API time query results

[development_sho]

I believe there is an issue in the Orders API in it's treatment of times.

I made a change to a paid order in my developer shop on 14th September 2017 at 09:17 (2017-09-14T09:17:00) local New Zealand time. (Shop is in UTC +12 time zone)

If I do a GET request as follows

admin/orders/count.json?updated_at_min=2017-09-14T08:00:00&updated_at_max=2017-09-14T10:00:00&status=any&financial_status=paid

This correctly fetches back a count of 1 order

{
    "count": 1
}

If I then make a subsequent query for the order details using exactly the same time period criteria

admin/orders.json?updated_at_min=2017-09-14T08:00:00&updated_at_max=2017-09-14T10:00:00&status=any&financial_status=paid

I get no order back.

{
    "orders": []
}

However if I change the updated_at_min criteria and subtract 12 hours I get the order details.

admin/orders.json?updated_at_min=2017-09-13T20:00:00&updated_at_max=2017-09-14T10:00:00&status=any&financial_status=paid

{
    "orders": [
        {
            "id": 5737111377,
            "updated_at": "2017-09-14T09:17:59+12:00",
            "number": 18,
            "financial_status": "paid"
        }
    ]
}

This shows an inconsistency in the way the requested dates are being treated. It appears as if the Orders call is treating the order as if it were updated at the UTC time NOT the local time (UTC +12) whereas the call to Orders count is treating the order as if modified at local time (UTC +12)

It makes no difference if I explicitly add UTC time zone designator to the unchanged updated_at_min parameter. This appears to be completely ignored.

admin/orders.json?updated_at_min=2017-09-14T08:00:00+12:00&updated_at_max=2017-09-14T10:15:00&status=any&financial_status=paid

Returns no orders.

This means that because we are incrementing the checking period each call, the sales will never be fetched because the request period is always 12 hours ahead of when the system thinks the orders were modified.

This appears to have been broken recently because several of our clients are now complaining that the Shopify orders are no longer being imported to their POS system.

Please advise. We are reluctant to put in a workaround of subtracting 12 hours due to the inconsistency of the two API calls and also because of  impending daylight savings adjustments.

[vix]

Hi There! 

Victoria here from Shopify. I took a look at your query and wanted to suggest encoding your `+` sign for the time zone aspect of your query. For example: 

admin/orders.json?updated_at_min=2017-09-14T08:00:00+12:00&updated_at_max=2017-09-14T10:15:00&status=any&financial_status=paid

Should actually read as (Note the use of %2B rather than using + ) 

admin/orders.json?updated_at_min=2017-09-14T08:00:00%2B12:00&updated_at_max=2017-09-14T10:15:00&status=any&financial_status=paid

As a rule of thumb, any non-alphanumeric character should be URL encoded for best results. 

Hope that helps! 

Victoria 

[dancooke]

Hey Vix, 

I'm trying to achieve a similar thing, but via the Graph API. I want to return only data which has been updated after a certain timestamp. I've tried the below but it doesn't seem to work: 

{
orders(first: 1, query: "updated_at_min:'2021-10-21T23:39:20Z'") {
edges {
node {
id
customer {
id
}
agreements(first: 5) {
edges {
node {
id
happenedAt
app {
id
}
... on RefundAgreement {
refund {
id
}
}
sales(first: 5) {
edges {
node {
id
actionType
lineType
quantity
... on ProductSale {
lineItem {
id
}

(cont...)

[development_sho]

Hi,

I have implemented your suggestion of URL encoding the + sign (I think this should be made clear in the documentation for the APIs by the way) This does not address my main issue in that the two calls to fetch orders and order count behave inconsistently.
This allowed me to fetch the order correctly last week, but now that we have had a change to daylight savings it is no longer working correctly and I am not getting the orders back propertly.
I implemented the offset by querying the for the Shop details and parsing the time zone (currently this shows GMT+12:00 which is correct)  and use this to then append the time zone offset to the updated_at parameters. However I created a new order this morning at 09:51 am New Zealand local time. I then queried for the Shop details and got the +12 offset.

{
    "shop": {
        "timezone": "(GMT+12:00) Wellington"
    }
}

This results in the query

/admin/orders.json?updated_at_min=2017-09-25T09:45:00%2B12:00&updated_at_max=2017-09-25T10:00:00%2B12:00&status=any&financial_status=paid&fields=updated_at,id,number,financial_status 

No orders were returned.

I changed the query to use updated_at_min one day previously and got the following result

{
    "orders": [
        {
            "id": 5897221009,
            "updated_at": "2017-09-25T09:51:53+13:00",
            "number": 19,
            "financial_status": "paid"
        }
    ]
}

As you can see the updated_at for the order is showing +13 which is incorrect and is why my original query is not working. NZ will not be 13 hours ahead of GMT until UK changes their time on 29th October when they put their clocks back an hour.

The order count query using the %2B12:00 also does not return a sales count, however it does if I do not explicitly set the time zone offset. eg

admin/orders/count.json?updated_at_min=2017-09-25T09:45:00&updated_at_max=2017-09-25T10:00:00&status=any&financial_status=paid

Removing the timezone offset does not work when querying order details.

Unless I am missing something, I cannot see how I can consistently create a query to fetch orders reliably.

Can someone please sort this out. It has become very frustrating for our customers, and I would expect the time zones to be managed properly at the Shopify end and not have to put hacks in to our system to test for dates and daylight savings every time a call is made to Shopify and also to change the query time periods depending on whether querying for orders or order counts.
 

[Jamie_D_]

Hey there,

There seems to be some confusion about time zones in your post.

Time zones are represented by an offset from UTC. UTC never, ever changes. UTC is a standard time representation which happens to be the same as GMT for historical reasons.

The UK switches from GMT to BST in the Summer – the time zone currently being observed in the UK has no affect on UTC (or GMT).

UTC+13:00 is indeed the correct representation of the current time zone being observed in NZ, as they are currently observing daylight savings time.

[development_sho]

Okay, thanks I guess I did misunderstand UTC offset, but I still have some questions about how to get the UTC offset when I query for orders.

Should I be able get the UTC offset from the Shop details query?

admin/shop.json?fields=timezone

I know I can get the UTC offset in code from the local PC where application is running, but this assumes that the PC is in the same time zone as the Shop. If someone has a best practice method to get this I would be grateful thanks.
 

[Jamie_D_]

Unless I am missing something, I cannot see how I can consistently create a query to fetch orders reliably.

I just spent some time testing this.

If you always explicitly provide a time zone, you shouldn't experience any issues.

The count endpoint implicitly sets the timezone in the query to the shop's timezone (if a timezone is not explicitly provided), while the orders index endpoint implicitly sets the timezone to GMT. This is admittedly confusing, but it's unfortunately something that we're not able to change at this point as we don't know how many clients are relying on this behaviour. 

{
    "shop": {
        "timezone": "(GMT+12:00) Wellington"
    }
}

This value shouldn't be relied on for determining the actual time zone that the shop is observing – the shop's timezone is a static record, so the offset displayed will not update based on whether or not the timezone is observing DST.

The timezone on an individual order will always represent the absolute time when an order is created, regardless of any DST observations.

tl;dr Always explicitly provide a timezone. Timestamps without timezones are ambiguous at best.

Cheers!

[Jamie_D_]

As for retrieving the shop's current UTC offset, the UTC offset displayed in any of the resource timestamps (such as order.created_at) will reflect the actual UTC offset of the time zone the shop is currently observing. 

I agree that it would be ideal to have the shop's actual current UTC offset described in the Shop payload. I'll see what I can do about that, but can't make any promises.

Anyway, hope this helps!

[development_sho]

Hi, 

Thanks for putting some time in to this.
 

The count endpoint implicitly sets the timezone in the query to the shop's timezone (if a timezone is not explicitly provided), while the orders index endpoint implicitly sets the timezone to GMT. This is admittedly confusing, but it's unfortunately something that we're not able to change at this point as we don't know how many clients are relying on this behaviour.

This behaviour seems to be something that has changed recently because our application has never specified an explicit time zone and has worked for years. It is only recently that orders failed to be returned.

Nevertheless I will make sure to add an explicit time zone offset from now on.

Thanks

[rizwan_ullah]

hy can anyone please help me. how can i create an order using ionic application