samvera
Control how JSONValueMapper::DateValue casts strings to dates
When deserializing the JSON data from Postgres, strings are cast to DateTime objects based on pattern matching. This results in dates such as 2019-03-10 getting cast as a DateTime. This isn't ideal as it creates some unintended consequences for users, who might want this to be preserved as strings instead.
We ought to provide a means of configuring this process so that if users want certain metadata to be cast to specific types, they can specify when and how that might occur, instead of relying on the present pattern-matching logic.
Strategy
Add a shared spec that saves a field that has both a DateTime and a string that's an ISO8601 string, ensure after reload it comes back as a DateTime and a string.
Valkyrie should know if a user tried to store a string which looks like a date or an actual DateTime object.
We are running into the same issue described in this ticket. In our specific case, we have strings that look like 1946-03-05T20:30:00 that get converted to DateTime objects, but we actually want these to stay as String. Currently, I am using Strict types so when the resource is deserialized it raises an error because the types don’t match. We could use the default coercive type instead of the strict type, but that causes the date value to change from 1946-03-05T20:30:00 to 1947-02-05T20:30:00+00:00. Because the coercive type is trying to stringify a DateTime object it automatically adds in a timezone. That's undesirable because it changes the value. A date might not have a timezone because it's unknown.
The PR above provided a stop-gap solution by only serializing strings that contain a T into DateTime objects. Could we expand on that and require that a serialized DateTime object also have a timezone/offset present?
Taking inspiration for awead's temporary fix, I implemented a similar solution in our project that requires a full timestamp with offset before converting a String to a DateTime object. This doesn't completely solves this issue because problem reappears if a String includes a timestamp (ie. 1947-02-05T20:30:00+00:00). But, I am happy to contribute this back.