This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-24
Channels
- # aleph (1)
- # announcements (22)
- # atom-editor (11)
- # babashka (46)
- # beginners (60)
- # calva (44)
- # cider (18)
- # circleci (1)
- # cljdoc (12)
- # cljs-dev (5)
- # cljsrn (19)
- # clojars (3)
- # clojure (162)
- # clojure-dev (9)
- # clojure-europe (6)
- # clojure-italy (2)
- # clojure-losangeles (2)
- # clojure-nl (5)
- # clojure-spec (7)
- # clojure-uk (23)
- # clojureremote (1)
- # clojurescript (55)
- # community-development (14)
- # core-async (234)
- # cursive (14)
- # data-science (3)
- # datomic (32)
- # fulcro (5)
- # graalvm (20)
- # graphql (2)
- # hugsql (4)
- # jobs (11)
- # jobs-discuss (2)
- # joker (1)
- # juxt (3)
- # kaocha (1)
- # luminus (1)
- # off-topic (33)
- # pathom (3)
- # pedestal (1)
- # reagent (24)
- # remote-jobs (3)
- # shadow-cljs (38)
- # spacemacs (4)
- # specter (4)
- # speculative (54)
- # tools-deps (62)
- # vim (8)
- # vscode (14)
Since I write C# at work, cannot help but think the following. If mainstream OOP languages had a tag line, it would be, "Why write 1 line when you can do the same thing in 100 lines?".
I feel enterprisey languages spend too much time making itself idiot proof. Then there's the onslaught of unwritten rules you have to Google every damn time (IDisposable for example.) Ever tried coding in a straight jacket? While it's certainly possible, it's not recommended.
you're right! I'm guilty of idiot-proofing my own code but as soon as I try and use someone elses idiot-proofed code that insists on implementing 5 different interfaces I start cursing the heavens
since picking up Lisp(s) I try not to get involved with type system puzzle solving any more
Exercism is looking for maintainers. Perhaps you can help out with fleshing out the Clojure track? https://twitter.com/exercism_io/status/1215288391656448000?s=20
worth a post in #announcements imo
Hi, I wonder how everyone stores time. My preferred way to carry time over the wire has become the ISO 8601 format. I guess it makes sense to store that with timezone in the database. Like Postgresql supports timestamp with timezone for instance. Any opinions on that?
We store in UTC ISO 8601 timestamp with timezone on postgresql (the server timezone is set to UTC)
Beware the it's often only offset that is stored in the db, not the actual timezone. This may be a problem with daylight savings and timezone changes. Especially when you're making an app for planning events in the future or similar. This is a good read: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
Thanks for the link. I decided to store timestamp with time zon and not utc after reading some more.
I prefer storing timestamps always in UTC. Dealing with timezones is error prone and I want to limit those errors to the presentation layer and leave db and business logic free from that.
Just to give a counter voice; https://www.google.nl/amp/s/codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/amp/
Hehe ^^
my experience from fixing dates in a database: • Brasil gov decided to backdown on the DST hour change, so we got to update 2M of entries which will get invalid dates after nov 2019. • the source for the date was expressed in local time, but developer decided it would be better store them in UTC. Ghost hours can not be converted on runtime back to local time. Conclusions: • Store the data faithfull to the source. • Do convertions on runtime, don't store the converted dates • Is you're not scheduling processes represent dates as string. • Rather than writing a smart update clause, just go entry by entry by id, it will take more time, but you will know what you change in case you mess up
This is a good read if you’re going to use postgres http://blog.untrod.com/2016/08/actually-understanding-timezones-in-postgresql.html
@valtteri Thanks I am looking at it. Back then I used the same approach, Timestamp in utc on the server, but since I started using the ISO format everyhwere it is tempting to store it like that in the database too.
How about UNIX timestamps, i.e. seconds since epoch? That's timezone agnostic as well, right? I am not an expert and genuinely curious.
Someone at work was testing some stuff last month and entered a date twenty years in the future... and things broke... I hope to have retired from software development well before then 🙂
y2k38 is only 18 years plus change away! 🙂
Long to the rescue!
I wonder if we will see the day where IPv6 is running out of adresses when all the planets in our solar system are under bot control and every nanobot has its own IP.
You can assign an IPv6 address to each grain of sand on approximately 340 billion planets like earth according to https://skeptics.stackexchange.com/questions/4508/can-every-grain-of-sand-be-addressed-in-ipv6
I'm sure IPv8 will be created with larger addresses, when it is needed. And then will take decades after that to become mainstream.