You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 12, 2024. It is now read-only.
we are using the client, and the experience is very nice so far.
we noticed that the date types used for some fields do not reflect the data we get from the duffel API, which causes inconsistencies when we serialize/deserialize data using the types from the library.
If the date is something like "2020-06-13T16:38:02" for example in "offers.slices.segments.arriving_at" it can be represented with "LocalDateTime" as we can get the zone information from "offers.slices.segments.destination.time_zone" (no problem here)
the problem occurs when we have a date string like "2020-02-12T15:21:01.927Z", which should be represented with a date type that supports zone/offset information like "ZonedDateTime"
here is a poor visualization of what happens when we deserialize and serialize back;
"2020-01-17T10:12:14.545Z" (String) -> "2020-01-17T10:12:14.545" (LocalDateTime, notice time zone is gone) -> "2020-01-17T10:12:14.545" (String, without timezone)
I am planning to fix this issue by changing the data type "LocalDateTime" to "ZonedDateTime" in places where the data is "UTC", and keep "LocalDateTime" where it is not.
I will create a pr for the fix as soon as possible, please let me know about your thoughts on this!
best regards,
Çağrı
The text was updated successfully, but these errors were encountered:
hello,
we are using the client, and the experience is very nice so far.
we noticed that the date types used for some fields do not reflect the data we get from the duffel API, which causes inconsistencies when we serialize/deserialize data using the types from the library.
If the date is something like "2020-06-13T16:38:02" for example in "offers.slices.segments.arriving_at" it can be represented with "LocalDateTime" as we can get the zone information from "offers.slices.segments.destination.time_zone" (no problem here)
the problem occurs when we have a date string like "2020-02-12T15:21:01.927Z", which should be represented with a date type that supports zone/offset information like "ZonedDateTime"
here is a poor visualization of what happens when we deserialize and serialize back;
"2020-01-17T10:12:14.545Z" (String) -> "2020-01-17T10:12:14.545" (LocalDateTime, notice time zone is gone) -> "2020-01-17T10:12:14.545" (String, without timezone)
I am planning to fix this issue by changing the data type "LocalDateTime" to "ZonedDateTime" in places where the data is "UTC", and keep "LocalDateTime" where it is not.
I will create a pr for the fix as soon as possible, please let me know about your thoughts on this!
best regards,
Çağrı
The text was updated successfully, but these errors were encountered: