it would be better to use a method which implicitly supports timedeltas. currently, recipients have to manually breakout the custom datetime string in order to do time comparisons. I'm not aware of a timestamp format that is both length-deterministic and supports timedeltas.
since dates outside 1966:2286 will reasonably never be valid, it is probably better to use unix time and simply reject timestamps that are not ten digits long
it would be better to use a method which implicitly supports timedeltas. currently, recipients have to manually breakout the custom datetime string in order to do time comparisons. I'm not aware of a timestamp format that is both length-deterministic and supports timedeltas.