Fork me on GitHub

There was discussion last week about supporting LocalDates in malli, but is that the way to go if I don't actually have schemas, but would like to get reitit to not die when it tries to encode LocalDates into transit+json?


The other option I guess would be to follow example, that was for Instants?


Ok, so the latter way is the one. Just need to figure out the transit parts, then


It does have unncessary dependency on joda-time though and uses format/parse fns from time-literals lib


also it makes the handler maps private, which is really strange, as exposing those should be the main API


Good point, I was also thinking that the write-transit function is not really helpful here


I need to read more about transit protocol, but I'm guessing it's also writing it as custom types, that can only be read with the same library

juhoteperi12:12:28 (this uses joda-time) doesn't need much else, java-time toString already outputs ISO formatted string and parse might be enough to parse those


Indeed, the transit tag for time is just "t"


Yes, I also use custom tags ~always.


That's good enough for your own clients, but I was hoping for a solution that works without customizing the reader. But I haven't given enough thought about it to decide if that even makes sense, since the different time types are distinct for a good reason


Might be that I'm thinking about it too far, and shouldn't look further than our own frontend, and keeping the stable, public API JSON only


transit time tag only covers instants as milliseconds since epoch, if you try formatting anything other than instants in that tag, you will be losing information


LocalDates don't have timezones though, so wouldn't they survive just fine?


No, even if you store LocalDate as ms since epoch in UTC, the information about original type will be lost and client will read it as instant


Especially in browsers that means that browser does stupid things with the instant


That's certainly true