Module: schema | Convex Developer Hub
I was trying to create a timestamp or datetime field in the table schema and to my surprise was not able to find such class on https://docs.convex.dev/api/modules/schema#s .... can we get something to work with times in the schema (for cases other then _createdTime)?
Module: schema | Convex Developer Hub
Utilities for defining the schema of your Convex project.
13 Replies
Maybe I should use
object ? That seems unsafe / doesn't convey the intent well, lol 🙂It supports the base datatypes supported by the convex database (https://docs.convex.dev/using/types). _creationTime is stored as milliseconds since unix epoch
in the dashboard - we sorta hard code that column as a date. We don't (currently) support a way to mark another column as a date in that sort of way.
ok so my use-case is to see when people last opened the site
It's really just eye-candy on the dashboard. It's stored as milliseconds since epoch.
I ended up storing the string for that
because I also want eye candy! 😆
yes - it's a good idea. Definitely helpful.
and don't want to build any UI for this functionality (just look in DB)
I think Date is a pretty important type to have first class support for imo
Yes agreed.
But it's possible we might be able to solve the main painpoint w/o scoping it all the way up to first class date support.
Perhaps we could have some way on the dashboard to "view as timestamp" or something like that if we detect the number to smell like a timestamp. So it's really just eyecandy (just like _creationTime)
I see, yeah that would work!
Are there other non-dashboard ways in which date columns might be helpful like this?
I don't know enough about javascript to have an insights here. If you tell me that milliseconds since epoch is good enough for _createdTime, I trust you 🙂
that it's good enough for other cases
I'll write something down. Maybe we can make something work.
your workaround of storing as a string should be pretty good in the meantime
I guess one pet peeve with my current approach: I had to store the string in Pacific Timezone for the usability for us. But that just feels wrong as an engineering thing 🙂
Times should not be in Pacific Timezone