Conversation
My gut tells me to store and retrieve as datetimes, and only go to/from strings on (de)serialization. That implies that it's awkward to intentionally store as a string in Very open to different models, though, so curious what ya'lls instincts are. |
| collection_as_dict = collection.to_dict() | ||
| for key in ( | ||
| "title", | ||
| "stac_extensions", |
There was a problem hiding this comment.
I think it's actually better to include an empty list for stac_extensions. That seems like a very common pattern in stac.
ab24538 to
2f64818
Compare
I think your instincts are good. I updated this PR make all the regular datetime fields convert to |
ircwaves
left a comment
There was a problem hiding this comment.
This looks good. A question and suggestion.
Co-authored-by: Ian Cooke <ircwaves@users.noreply.github.com>
|
@gadomski do you want to take a look at this one? I think it would be best to merge it before working on item_collection and catalog tests. |
gadomski
left a comment
There was a problem hiding this comment.
LGTM! Sorry about the slowness on review
Related Issue(s):
Description:
The big question that came up in this work was: do we want datetimes to be
dt.datetimeor iso strings? So far v2 has theDateTimeprotocol defined in common_metadata.py has datetimes stored as strings inextra_fieldsbut returns them asdt.datetimewhen accessed as a property. This is what is used byitem.properties. ButSpatialExtentjust uses strings