[Feat]: Change pickup_min_datetime and pickup_max_datetime Shipment Options types to string

[gkeasypost]

Feature Request Is New

• I have verified that the requested feature does not already exist or has not already been requested.

Description of the feature

In the Options model, the pickup_min_datetime and pickup_max_datetime options should be a string type instead of a DateTime type in order to maintain consistency with what the EasyPost API returns for those options, as well as the same type as delivery_min_datetime and delivery_max_datetime.

see:
https://www.easypost.com/docs/api#options
https://github.com/EasyPost/easypost-csharp/blob/master/EasyPost/Models/API/Options.cs#L683
https://github.com/EasyPost/easypost-csharp/blob/master/EasyPost/Models/API/Options.cs#L689

[nwithan8]

Hey, thanks for reaching out! This is being discussed internally about the best way to handle non-primatives, particularly dates, in our client libraries, whether to keep them as strings as they are in the raw JSON, or whether to de/serialize them to language-specific elements (e.g. a DateTime in .NET).

Right now, it seems there is a mix of both throughout the library, so we will try to standardize it one way or another via a breaking change release.

We'll keep you updated. If any other developer would like to weigh in on what would be suit their expectations, please chime in!

[joe-rohde]

Standardizing these dates is important for working with different carrier requirements. Is there a timeline on when this will be addressed?

[nwithan8]

Hey Joe Rohde (@joe-rohde) , thanks for weighing in.

Unfortunately, we do not have a projected timeline or any updates to share regarding this.

If you could, can you elaborate on how the DateTime versus string type of a date is interfering with your usage of EasyPost? It will help us diagnose the issue and influence our decision about which paradigm to adopt.

[joe-rohde]

We utilize multiple date fields across multiple carriers. An example of one issue we are having is with the carrier CDL. They require specific time windows for picking up and delivering. When posting to the Easypost endpoint, we set specific date/times: - "pickup_min_datetime": "2023-09-21T06:00:00" - "pickup_max_datetime": "2023-09-21T08:00:00" - "delivery_min_datetime": "2023-09-21T08:00:00" - "delivery_max_datetime": "2023-09-21T20:00:00" EasyPost converts these dates to different ways: - "pickup_min_datetime": "2023-09-21T06:00:00.000Z" - "pickup_max_datetime": "2023-09-21T08:00:00.000Z" - "delivery_min_datetime": "2023-09-21T08:00:00+00:00" - "delivery_max_datetime": "2023-09-21T20:00:00+00:00" These dates are sent to CDL through EasyPost with the converted date/times as displayed above. This is causing the wrong date/times being populated in the CDL system. As you can see, this inconsistency provides a challenge on supporting different carrier requirements. I am not opinionated on string vs datetime. The .NET types should match the API. Both pickup and delivery fields are a string type in your API documentation. Thanks, Joe Rohde Coldcart, Inc. - CTO

[joe-rohde]

Any update on the effort in standardizing the datetimes in the API?

[Justintime50]

Hey Joe, thanks for the example with CDL. Mind supplying a few more details so we can investigate the root cause further? You mentioned you are seeing a discrepancy with the datetimes you provided and what the API returns and that it’s causing the wrong datetimes in the CDL system - can you elaborate on the affect of that behavior? The datetimes provided appear the same with the exception of the response containing the timezone as UTC, is that what is causing the wrong datetimes? If so, does supplying your desired timezone in the datetime correct the problem? Our system will default to UTC when no timezone is supplied which may explain the discrepancy.

If that isn’t the problem or doesn’t correct the discrepancy, it would be helpful to have a shipment ID for a recent purchased CDL shipment that contains this problem so we can check it on our end.

We are still determining how to unify the datetime fields in this library and have no immediate plans to ship a breaking change release of this library to accomplish that. In the meantime, I’d love to help you get these datetime option fields working with CDL if possible.

[Justintime50]

Hey Joe Rohde (@joe-rohde), are you able to respond to the above with more info? It would help us know better how to proceed.

[nwithan8]

This issue boils down to that this is the raw string from the API, while this gets converted from the raw string into a DateTime object which, when converted back into a string via something like a .ToString() method, is converted into a different %H:%m:%s-like format.

The end user could change the format used when stringifying a DateTime object to standardize it, or the SDK could use DateTime consistently for all date/time strings returned by the API.