Tran Vu

Thanks @paulostp,

Please note that, by default, the processes that export orders to ShipStation.com always overlap by several hours. No orders should be falling through the cracks due to timezone differences.

It could be only our case however we are talking about 15 hours earlier. The shipstation log indicates the requested window is only 2 hours (see below). So if shipstation’s server is 3 hours earlier than your web server there could be some orders are exported and some aren’t. If it is more than 4 hours then i think nothing will be exported.

action=export&start_date=03%2F03%2F2023+14%3A32&end_date=03%2F04%2F2023+16%3A06&page=1

We have had this problem since version 4.1.48 as a result we stuck with version 4.1.46 for a while until I decided to investigate further. I contacted Shipstation and they told that if they backdate the request by a day then orders are exported but if leave it by default nothing happened.

By removing strtotime() in line 80 and 94, everything work as it is supposed to be. This actually is what it was in version 4.1.46 and earlier. There are a few topics in support forum saying orders are not export but they are all closed without an answer so i’m not bordering to open another topic.

We had similar problem after upgrade the plugin a while ago . It seems to be because of the different timezone between Shipstation server and WC server. Our WC server is in US while the Shipstation in AU as a result, the requested time is in the future thus the API find 0 order to export and there will be no error or warning at all.

The temporary fix is edit plugin file in “includes/api-requests/class-wc-shipstation-api-export.php”

Line 80 and 94

Change from : ‘date_modified’ => strtotime( $start_date ) . ‘…’ . strtotime( $end_date ),

To : ‘date_modified’ => $start_date . ‘…’ . $end_date,

The strtotime() function doesn’t contain timezone information so if the request come from a server that is way earlier can cause the headache.

Hope it could help and hope to see the fix in next release.