This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-05
Channels
- # announcements (8)
- # asami (70)
- # babashka (28)
- # beginners (163)
- # calva (7)
- # cider (15)
- # clj-kondo (47)
- # cljs-dev (45)
- # clojars (2)
- # clojure (56)
- # clojure-europe (24)
- # clojure-italy (1)
- # clojure-losangeles (2)
- # clojure-nl (4)
- # clojure-spec (2)
- # clojure-uk (53)
- # clojurescript (46)
- # data-oriented-programming (15)
- # data-science (10)
- # datahike (2)
- # defnpodcast (1)
- # depstar (27)
- # emacs (35)
- # figwheel-main (28)
- # fulcro (38)
- # girouette (1)
- # graphql (16)
- # jobs-discuss (3)
- # kaocha (9)
- # keechma (2)
- # leiningen (6)
- # lsp (87)
- # malli (19)
- # membrane (16)
- # pathom (4)
- # re-frame (11)
- # shadow-cljs (25)
- # spacemacs (2)
- # testing (12)
- # tools-deps (14)
- # tree-sitter (4)
- # xtdb (20)
I have a ISO timestamp string like so 2021-03-20T07:00:58.000Z
What’s the most convenient and least error prone way to convert it into a date and a time according to a specific timezone?
in a format like so: March 3, 2021 6 pm
@henryw374 the link has the following but I don’t know how to convert it into cljs:
new Intl.DateTimeFormat().format(date)
I tried this:
(.format (.DateTimeFormat (js/Intl.) "en-US") date)
but it’s giving Intl is not a constructor
if you're not at a repl already... it's a great way to work out interop syntax ... and do everything else 😉 online one http://app.klipse.tech/
cljs.user=> (.format (js/Intl.DateTimeFormat. "en-US")) "3/5/2021" cljs.user=> (-> (js/Intl.DateTimeFormat. "en-US") (.format (js/Date.))) "3/5/2021" cljs.user=>
As an aside, I notice that “en-GB” in the above still gives me 3/5/2021, not 5/3/2021 which I’d expect. The plain Javascript looks good:
> new Intl.DateTimeFormat('en-US').format(new Date())
'3/5/2021'
> new Intl.DateTimeFormat('en-GB').format(new Date())
'05/03/2021'
After I posted, I started to wonder whether it was because for the CLJS I used a bespoke Node that’s bundled with another application (where for the plain JS test it was the standard Node). I’m going to guess that’s the issue and will investigate.
the .
invokes it with new
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new, . not sure if that makes a diff in the case of this fn but the docs all show it being invoked with new
so I'd stick with that
btw @ps if you're doing much work with dates, including formatting, I would recommend https://github.com/juxt/tick (which I maintain). atm it's quite a lot of code though, so not everyone's cup of tea . see https://github.com/juxt/tick/blob/master/docs/cljs.adoc#optional-timezone--locale-data-for-reducing-build-size
For me the biggest stumbling block was dealing with the extra dependencies from ClojureScript (apart from the recent issue I reported I actually tried using tick a few months ago but gave up at the time because I couldn’t make it work in ClojureScript, and for me the Clojure + ClojureScript code re-use is one of the biggest wins of any library that is heavily used across both languages)
Do you think there’s a way to bundle the extra dependencies as part of deps.edn somehow? Perhaps that’s similar to how ClojureScript bundles the google-closure compiler (if I’m not mistaken) : https://mvnrepository.com/artifact/org.clojure/google-closure-library
it does include those extra dependencies as foreign libs already. so you don't need to bring in the npm deps. but since you are using npm anyway, I'd expect you'd prefer to get them via that route
I see that they are included under Dependencies, cool https://clojars.org/tick
but e.g. if you use reagent as well, then you would already do that npm step, and that would pull in tick npm deps as well
So you’re saying that any use of yarn/npm would pull the juxt/tick dependencies into package.json ?
Or just the use through ClojureScript tools/methods like :
clj -m cljs.main --deps-cmd "yarn" --install-deps
I generally don’t use any of the clojurescript means, just use: yarn add yarn install etc directly
So you’re saying that if I remove all juxt/tick dependencies from package.json, the library should still work (in theory)
and for non-shadow build, if you do use --`install-deps` , then you need to exclude the foreign-libs, otherwise you'll end up with 2 lots of them in your build, which is definitely not small
Ah, good point… so why wouldn’t I just stick with the foreign-libs? (for my case, given that I avoid most other ClojureScript+npm/yarn tooling combos)
Actually, now I recall trying the foreign-libs route some months ago. Is the foreign-libs route expected to work with :advanced ? (I think that was the stumbling block I hit back then)
The tests are done with advanced. And all my work builds use advanced with foreign libs
I have the following where iso is the iso string coming from a database.
(defn get-local-date [iso]
(js/console.log "iso is " iso " " (= iso ""))
(if (and iso (not= iso ""))
(let [date (js/Date. iso)]
(js/console.log "date is!!! " date)
(->
(js/Intl.DateTimeFormat "en-US"
#js {:dateStyle "full" :timeStyle "long"})
(.format date)))
""))
when I print
(get-local-date iso-string)
I’m getting the following:
3/20/2021
Whereas after putting #js {:dateStyle “full” :timeStyle “long”}, I expect a longer date like “March 20, 2021". What am I doing wrong?