Closed grizzm0 closed 6 years ago
I'm not quite sure how we should go about this, to be honest.
DateTime
does not implement either __toString()
or JsonSerializable
, so we cannot rely on either of those two methods to get the string version. You also cannot cast it to a string (e.g., (string) $date
).
What json_encode()
appears to do is serialize it to an object with the keys date
, timezone_type
, and timezone
... none of which follow any RFCs or ISO standards from what I can tell.
What we could do is call $date->format('c')
, which uses ISO 8601, which any consumer should be able to pass to its own language's date-time facilities without error. Thoughts?
I'm just afraid people are already used to the json_encode format and might be using it in the wild. Although, as the package is still pre stable there's nothing that stops us from breaking it.
I myself already got an interface in my frontend to match the json_encode output. This is code I've been using before expressive-hal tho when I used json_encode myself.
Either format('c') or format('r') would probably work. r seems to contain a bit useless information tho and therefore c would probably be better. momentjs as an example checks for ISO 8601 first.
XmlRenderer::createResourceElement() does not have support for PHPs DateTime object. As this works natively in json_encode() I feel like XmlRenderer also should have support for it to be consistent between the two.
Exception:
Encountered non-primitive type "DateTime" when serializing Zend\Expressive\Hal\Exception\HalResource instance; unable to serialize