Date is not a supported Convex type
I have an action which returns an object with some "Date" type properties.
When returning the object I get:
Uncaught Error: Date "2023-09-09T00:00:00.000Z" is not a supported Convex type
Is there a special way we should be dealing with Dates in Convex?7 Replies
We recommend storing dates as timestamps in milliseconds, with
date.getTime() and new Date(date) to convert back and forth. This way the date is portable across time zones. They're not supported in Convex as dates because of the differences between languages and platforms. (many databases store seconds, while languages use nanoseconds or milliseconds, and some are timezone-aware while others are "naive"). To avoid confusion, we recommend storing as a number and converting at both ends.Thank you for your response and advice, I will follow it when it comes to DB data.
My specific problem was returning values from an action. Which from my understanding is json stringifying the result and sending it in the json body of the response.
If you're using some custom serializer, is there any way to extend it so date objects are serialized correctly (using standard ISO date format)?
Or I need to create my own serializer and use in each action/query/mutation?
Ah good point, returning values from an action also does not allow Dates. There's currently no way to add custom serialization -- it supports JSON and a few other types but not Dates -- but that does make sense. Thanks for the feature request, I'll check with the team
Thanks! Unless there's a very specific reason I'm unaware of to do things differently, I would suggest to use the default javascript JSON.serialize method when returning data from a function.
I understand that supporting custom serializers might be more work.
Also 1 more question that rose from your response. You said that actions support returning JSON? How do I return JSON? Do I just return a string?
sorry i mean actions support returning things that json serialization can round-trip, so strings, numbers, arrays, plain objects, etc. The trick with custom serialization via
toJSON is we might not be able to get the original object back when deserializingIn a custom serialisation we would be required to implement both a
toJSON and a fromJSON function :)
In any case, I don't think with a standard ISO 8601 date format as your default serialiser you would have any issues, as it's universally used and supported by the javascript Date class.
You can either treat all dates as UTC (2022-12-31T00:00:00.000Z) or include the offset in the string (2022-12-31T00:00:00.000Z+00:00), although the former is more common.The issue here is these are strings — we'd need (and we do think about this for custom serialization) some knowledge that
'2023-10-23T19:31:51.699Z' is a date, not the string '2023-10-23T19:31:51.699Z'. Since we can't reconstitute the Date on the client, our types would say "this function returns a Date" but it would be a string.
Some systems like superjson do this by using a custom serialization format (say { $date: '2023-10-23T19:31:51.699Z' }), others use an API spec to decode the data correctly. We'd probably want to do one of these things instead of .toJSON() on dates and losing the information that it was a date on the server, but agreed its annoying not to be able to just return a date.