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
The v1.0.0 TOML spec allows omission of the time or date portion of a local date-time to represent a local date or a local time respectively. However, there is currently no implementation for Serialize or Deserialize for Date or Time in the toml crate. While it is possible for consumers of toml to use Datetime, it would be better to be able to use Date/Time directly to more clearly communicate intent, prevent mistakes in making runtime assertions, and avoid the need to manually unwrap the date/timeOptions.
NOTE: I am not suggesting we interpret a local time as a duration as suggested in #696. RFC 3339 explicitly does not cover time intervals.
The text was updated successfully, but these errors were encountered:
I am fine with someone implementing this. I would expect the impl's to delegate to Datetime and then error if an unexpected field is set so we centralize all knowledge of the serde hacks we use to deserialize this time (and ensure full compatibility between them)
The
v1.0.0
TOML spec allows omission of the time or date portion of a local date-time to represent a local date or a local time respectively. However, there is currently no implementation forSerialize
orDeserialize
forDate
orTime
in thetoml
crate. While it is possible for consumers oftoml
to useDatetime
, it would be better to be able to useDate
/Time
directly to more clearly communicate intent, prevent mistakes in making runtime assertions, and avoid the need to manually unwrap thedate
/time
Option
s.NOTE: I am not suggesting we interpret a local time as a duration as suggested in #696. RFC 3339 explicitly does not cover time intervals.
The text was updated successfully, but these errors were encountered: