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
My implementation supports broader time parsing than liquid-rust, so I have a time::OffsetDateTime, and need a liquid::model::DateTime. Sadly, because inner is private, I have to serialize to a string and deserialize. I do this during batch imports and it's unnecessarily slow.
I understand that keeping the internal representation private is a reasonable decision given it gives you flexibility on representation later. I do think it might make sense to add an impl From<OffsetDateTime>, which sadly I cannot do from outside the crate given the visibility. This could obviously be feature flagged, and if you do change the inner implementation in the future, the implementation can just parse the OffsetDateTime into the new format, which is future proof and fairly low-cost.
today, the impl would be along the lines of
#[cfg(feature = "date-time-from-offset-date-time")]implFrom<time::OffsetDateTime>forDateTime{fnfrom(value: time::OffsetDateTime) -> Self{Self{inner: value }}}
The text was updated successfully, but these errors were encountered:
Alternatively, since a lot of what my implementation does mirrors the internal parsing, the ability to add formats to USER_FORMATS in some way would solve my problem - however, this has all the same visibility issues (exposing format_description! as part of this crate's supported API), and probably is much harder to test around, so I doubt this would be a preferred way of expanding support.
Internally, DateTime is represented as
where
My implementation supports broader time parsing than liquid-rust, so I have a
time::OffsetDateTime
, and need aliquid::model::DateTime
. Sadly, becauseinner
is private, I have to serialize to a string and deserialize. I do this during batch imports and it's unnecessarily slow.I understand that keeping the internal representation private is a reasonable decision given it gives you flexibility on representation later. I do think it might make sense to add an
impl From<OffsetDateTime>
, which sadly I cannot do from outside the crate given the visibility. This could obviously be feature flagged, and if you do change the inner implementation in the future, the implementation can just parse the OffsetDateTime into the new format, which is future proof and fairly low-cost.today, the impl would be along the lines of
The text was updated successfully, but these errors were encountered: