I often do stuff like:

(defn some-ui-component [opts]
  [:div {:class (concat '[bg-red-600 text-sm] (when ... '[px-4]) ...)}])

Thank you Jacob! That's what I've been doing, trying to avoid conflicts in the first place. But when I want a component with default styles to be customizable, that's when conflict-aware merging makes sense.

I'll try to see if I can whip up such a library myself.

Let me know if you do release anything; I'd definitely be interested in trying something like that out.

@U07SWUQTH did you ever end up rolling your own tw-merge solution?

No, I did not, sorry.

no problem!

i'm taking a stab at porting tw-merge to cljc. if i come right, i'll make it public 🙂

looks pretty interesting! I've put it on my list to check out soon.

You should save UTC in database always, since people move or sometimes you have a setting to change timezone, depends on the app. (Not even starting on daylight saving times and other fun parts). Once you have the time in UTC, you need to know current user timezone or offset that you can store along with user's session to render a proper time on screen. If you don't have timezone in settings then you need to grab it with javascript. Something like this: https://stackoverflow.com/questions/1091372/getting-the-clients-time-zone-and-offset-in-javascript. Or if you only do it for a short time you'll be good just grabbing a timezone offset (again, unless you end up on some DST day)

I'd also recommend leaving it in UTC. It gets less jarring once you get used to doing the conversion in your head whenever you see a timestamp ha ha. But if you really want to use the local timezone, you can remove this line from config.edn: https://github.com/jacobobryant/biff/blob/master/example/config.edn.TEMPLATE#L42

yeah i definitely want to store UTC in the database, I would just prefer to show them to the user in their local time zones

building a calendar feature so its kind of important 😛

Ah I glossed over the "current session" bit in your original post 🙂 in addition to what @U4EFBUCUE said, you could also get the timezone from the IP address. In prod it'll be in (get-in ctx [:headers "x-real-ip"]) ("x-real-ip" is set by nginx, so it'll be in a different header in dev), and then you can feed it to some IP lookup service (I've used https://ipapi.co/ myself). That'll give you both the timezone and the current UTC offset. to be clear, I probably wouldn't recommend doing that--just grabbing it from the client with javascript will be just as easy, and then you don't have to introduce a 3rd party service dependency. But it's another option to at least be aware of.

Or another approach--just send the UTC time and use javascript to render it; no need to fetch the user's timestamp at all: https://clojurians.slack.com/archives/C013Y4VG20J/p1692808765328769?thread_ts=1692778099.752249&cid=C013Y4VG20J