morning

morning

Morning

Morning all- cheers @jasonbell. I’m in Bristol and try as often as possible to get myself along to our Clojure (study) meetup. Found the UK channel and thought I’d stick my head in 😄

Morning all, anyone know of Clojure companies or meetups in the Oxford area?

I saw Juxt's blog post about Crossref (https://juxt.pro/blog/posts/clojure-in-crossref.html)

Morning 😃

o/

\o

YMCA

\o/ /o\ o< /o\

I am having quite the day, not in a bad way per se, but wow...

Y'All ok out there in UK Clojure-land?

I'm learning about Athena 🤓

All the major hat tipping and thank yous to @dominicm Aleph/Yada SSL demo on Github. Worked first time, thank you!

https://github.com/SevereOverfl0w/aleph-yada-ssl

Anyone got any idea how I can create a Transit reader that does not need a ByteArray as a parameter..?

There are 2016-vintage tutorials that show this:

(def r (cognitect.transit/reader :json))
(cognitect.transit/read r "{}")

type of thing, but when I try to create a reader like this I get an arity error and it seems__ to be the case that the /reader function wants a ByteArray and indeed for that to be the content I want to read... Have I misunderstood..?

I've looked at the sourcecode - I need to supply an InputStream, I can see that... Need to fix this tomorrow...

Morning

Going to post this here but I’ve also post it in #hugsql too.

I have a Luminus app that’s coercing times of dates incorrectly when they are pulled from MySQL.

| daa2f7fe-fafb-4525-8bac-c991c37b799b | 2018-11-30 13:00:00    |

#object[org.joda.time.DateTime 0x422e20d2 2018-11-30T07:00:00.000Z]

Wondering if @seancorfield has come across this one before?

And the local time of the db server is correct….

$ date
Wed  7 Nov 2018 21:16:53 GMT

@jasonbell where is the conversion code?

For jdbc reads

HugSQL handles all that

All I do is handle SQL queries.

What is the timezone of your database and what is the timezone of your JVM/application?

GMT, currently on the same machine

Hmm, I've only ever seen that sort of thing when the TZ of the JVM pulling the data is different to the DB...

user> (t/now)
#object[org.joda.time.DateTime 0x44cf71f4 "2018-11-07T21:21:03.981Z"]

And that's kind of an odd TZ offset to adjust by (6 hours). That's neither West Coast nor East Coast nor anywhere in Europe...?

My thinking too. I’ll keep digging around. If I come up with anything I’ll let you know.

I’ve got a work around if it all goes really wrong 🙂

Is it consistently wrong by 6 hours on all date/times coming from the DB?

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2018-11-07 21:22:38 |
+---------------------+
1 row in set (0.00 sec)

yes it is it’s weird. It might be some strange HugSQL bug, that’s the only black box bit I can’t see what’s going on

Which is kind of annoying.

But my choice at the time.

In your REPL, just as a sanity check, what do (java.util.Date.) and (clj-time.coerce/from-date (java.util.Date.)) return?

user> (java.util.Date.)
#inst "2018-11-07T21:25:04.296-00:00"
user> (clj-time.coerce/from-date (java.util.Date.))
#object[org.joda.time.DateTime 0x7621213d "2018-11-07T21:25:26.398Z"]
user> 

looks fine

Luminus/HugSQL combo is using Conman to do it’s SQL execution so I’m going to REPL that and see what happens

Two things to check

1) that your mysql client does not have some weird default time zone per session which auto-converts the time stamp

^ I’ve gotten bitten by that when my app was showing different times than my command line client

2) what happens if you store the data as time stamp without timezone? (Not sure what the MySQL equivalent of that type is)

oooh

we had a problem with 2 recently where with postgres it was pushing UTC times into BST

it was something silly like times were being coerced by some library wrong and we had to make sure everything had Z at the end or something