I think somethiing’s wrong with Dates and Times when creating orders via the API. When an order is created, I also need to set the time when it needs to be fulfilled. So, I’m using the field hold_until_date that does that.
We are using timezone “America/Santiago” (UTC -4). And this works fine when we push an order with a specific date. For example, we push an order with date “2022-08-30T20:00:00.000Z” and in Shiphero the time is shown correctly: “08/30/2022 04:00 PM”.
The problem is that the order’s “Hold Until Date” and “Hold Until Time” are not working correctly, the times that are being set are not aware of the timezone, so, with the same example, if I put hold_until_date with the value of “2022-08-30T20:00:00.000Z”, in Shiphero App it shows “08/30/2022 08:00 PM”, that is not what I expected. It has to be “08/30/2022 04:00 PM”.
I tried sending the orders with local time, i.e. “2022-08-30T16:00:00.000-04:00”. And, again, the order date is set correctly, but the order hold_until_date is showing “2022-08-31T00:00:00+00:00” and I don’t even know why.
If I send the order with hold_until_date in local time but without the timezone, (i.e. “2022-08-30T16:00:00”) it seems to work, but of course this is not an expected behaviour as it is not following the ISO 8601 time format.
I do believe that this issue will have to be escalated to our Engineering Team to be fixed. I’ll keep you updated here as the updates come in. Thank you for bringing this to our attention.
Please let me know if you have any questions or concerns!
Any updates on this? Im also having a hard time understanding how hold_until_date is supposed to work.
For example, I set the hold_until_date with an automation. When I get the order via api I can see that hold_until_date. If I resubmit that hold_until_date that I just received from ShipHero with an order_update mutation, now 5h get added to the hold_until_date .
I am not trying to resubmit the same date, I am just using this example to outline the issue.
Thanks for reaching out and welcome to our Developer Community!
This issue is still making its way to our Engineering Team, I’ll go ahead and bump it.
The bug here is that when you change the hold_until_date through the Public API it’s being displayed in UTC time in the UI when it should be in your accounts timezone.
Please let me know if you have any questions or concerns.
Good question! You made me wonder if it would happen so I gave it a try. And yes, this is an issue, because if you submit hold_until_date in a order_update mutation with the same value that you received from a order or orders query, you will find that the value is changed.
In my case, my account is configured with timezone GMT -03:00. So, I got an order with "hold_until_date": "2022-10-19T12:00:00.127000+00:00", then, passed the same value to an order_update mutation, and got that the value has been updated for +3 hours.
I believe that the API is not considering UTC time values for this specific fields, so it assumes that every value is set to the local timezone configuration.
It is something to consider if you’re updating orders with the same values as you get from the API.
The problem isn’t that the hold_until_date is displayed as UTC in the UI. It really changes the actual Hold Until Date value to a wrong one, so, for example, if your account configuration is GMT -03:00, then all of your orders will be on hold 3 more hours as you expected.
But then the problem gets bigger if you want to update an order. If you update an order by fetching all the data from the API, then update one or more values, keeping hold_until_date untouched, it gets changed anyway. So, every time you do an update, this value gets updated from +X hours, and enters in this endless loop of delaying the Hold Until Date value.
To be clear, this just happens with the hold_until_date field. All of the other date fields work as expected, using local and UTC timezones.
