Discussions

We have identified a timezone conversion issue affecting user and driver submitted timestamps.

observed behavior:

A driver submits or hits a geofence in local time (EDT) but the resulting timestamp is serialized in UTC without first converting the value:

Example: driver hits arrival geofence at 0356, EDI X3 is submitted as 2356z which is later Driver manually submits timestamp to mark task complete at 0357, EDI AF is submitted as 0357z - this is where the conversion is not occurring. This effectively changes the event by 4 hours instead of representing the correct point in time.

In our case, this causes a sequence issue where our customers cannot ingest the non sequential order of EDI events, causing a cascading failure of event reporting.

Is this a known issue and is there a timeline for a fox? This is a critical issue as timestamps are not being submitted correctly for high visibility and critical shipments, causing downstream EDI/API issues.

Our expectation would be that system generated times are generated in UTC and converted to local time on the front end. When a user submits datetime values, the conversion should apply in reverse, converting to UTC in the backend. This does not appear universal as some times are correct and others (mainly user generated datetime values) are not converted.