Clojurians Log v2

cast in XTQL should broadly work, e.g. https://play.xtdb.com/?version=2.0.0-b1&type=xtql&txs=W3sic3lzdGVtLXRpbWUiOm51bGwsInR4cyI6Ils6cHV0LWRvY3MgOmRvY3Mgezp4dC9pZCAxIDpmb28gMX1dIn1d&query=KC0%2BIChmcm9tIDpkb2NzIFt4dC9pZCBmb29dKQogICh3aXRoIHs6Zm9vMiAoY2FzdCBmb28gOnV0ZjgpfSkp

@nonrecursive fwiw we've had the same issues with Transit - we built on the excellent https://github.com/henryw374/time-literals library with https://github.com/xtdb/xtdb/blob/main/api/src/main/clojure/xtdb/mirrors/time_literals.clj in the XT repo - feel free to copy it too, it's permissive open-source after all 🙂 regarding the return type: as @taylor.jeremydavid says we store all three of those (Date, Instant, ZDT) as an Arrow timestamp, so it's unfortunately a lossy round-trip. we did consider returning timestamps with tz=UTC as Instants (and potentially still could with a config flag or something) - but this would just have shifted the problem to users putting in ZDTs and wondering why they get Instants out in certain cases 😅

Malli's got malli.experimental.time (https://cljdoc.org/d/metosin/malli/0.16.4/api/malli.experimental.time) that you can include in Muuntaja - but yeah, I share Sean's sentiments, it's been 10y now 😄

I guess I'd ask, why would you want a mostly deprecated Date type, rather than a modern Java date/time type?

fair question 🙂 the bigger picture is i’m trying to whip up a little prototype app and dealing with muuntaja/transit encoding for java.time is enough of a hassle that i don’t want to have to spend time on it in at this point in the app’s lifecycle like, i know it’ll be a good idea to use java.time but right now I don’t even know if this will even see the light of day and i want to get something working I can play with without having to take too many detours

halfway to getting transit encoding/decoding sorted 🙂

I'm a bit surprised muuntaja and transit don't already have built-in support for Java Time... it's been around since Java 8, which came out a decade ago...

I agree! it’s really just about transit. the muuntaja part is having to thread the transit config into where muuntaja lives in my middleware

I believe a j.u.Date is auto-coerced and stored as a TIMESTAMP WITH TIMEZONE (an Arrow timestamp, internally) and then can only be returned as a ZDT

I’ve found that transacting java.util.Instant also results in a ZDT getting returned, maybe for the same reason? saw that it’s possible to cast with SQL, but not XTQL afaict

Have you required next.jdbc.date-time to enable basic PostgreSQL support?

Yes I did and a time/date works. But I can’t get time/zoned-date-time.

Some types may not be fully implemented over pgwire yet (apologies!), but you should be able to work around everything, including ZDTs, using the transit type, e.g. per https://github.com/xtdb/xtdb/blob/9829b45d2599813b5847626ea66f26eefe5f9ce9/src/test/clojure/xtdb/pgwire_test.clj#L1877-L1889

Cool, what’s the tradeoff of using transit ? I guess it’s like storing end as string, you can’t use it in query ?

the transit (JSON serialization) is just a way of transferring values via the pgwire protocol, so once the data is stored everything is the same