Although MongoDB BSON has a Date object, strict JSON does not. In order to make representations of FireWorks objects compatible with JSON, the serialization engine automatically converts datetime objects to Strings. When deserializing, it detects Strings that look like datetime and converts them back into datetime objects.
Until now, no one had reported intentionally trying to store a datetime object as a String that they didn’t want converted back into a datetime. But, there will be an issue in doing this like you report - FireWorks will automatically try to deserialize this back into a datetime.
As a workaround, you can modify your String slightly to not be in exact datetime format (e.g., add a prefix or suffix). The two string types that FireWorks tries to automatically parse are:
Anything apart from those should stay a String.
Sorry for the inconvenience
On Thursday, October 6, 2016 at 8:18:41 AM UTC-7, [email protected] wrote:
I don’t know if it deserves to be noted, but I encounter something strange with a parameter passed to PyTask.
I passed date_aquisition as a string to the PyTask:
- “data_take_id”: “014CF7”,
- “date_aquisition”: “2016-09-18T17:22:46.000000”,
- “footprint”: “‘POLYGON((5.807076 45.420853, 9.092556 45.821396, 9.422935 44.322784, 6.221652 43.922112, 5.807076 45.420853))’”,
and the PyTask actually get date_aquisition as a datetime.datetime object in input (this string has indeed the default string dump format of a datetime.datetime object)
I guess this is caused by the deserialization of data structure stored in MongoDB, but I don’t know if it is intended or if it is a bug…