Hmm… It seems like it will always print to a string? https://github.com/clojure/tools.logging/blob/302cc2f095a0de7847c7d5590f37c5a7cc990954/src/main/clojure/clojure/tools/logging.clj#L94-L95

Depends what you mean by streaming data, but reducibles are nicer for managing the resources that are often associated with that kind of thing

There's also the "it depends" aspect of how you want to consume the data: do you want pull semantics or push semantics.

@U0NCTKEV8 i like how reducibles manage the resources, but unless i’m doing some wrong i find it hard to poke at in the REPL, for example let’s say you return a reducible HttpInputStream, once it’s reduced and i can’t reduce it twice because you call .close at the end of the reduction. That’s why i’m partial to use lazyseq even if immediate wrap it in r/reducer right after if that’s make sense… kind of academic concern though

@U0J3J79FE Shameless but relevant plug https://clojure-goes-fast.com/blog/clojures-deadly-sin/

In Clojure core there is format function, which is a thin wrapper around a Java method with printf-like format strings

I do not know of other options, but I'm sure there are several Java libraries that offer other things that others might know the names of off the tops of their heads.

another option, which is available but a bit more esoteric, is cl-format in clojure.pprint - it's an implementation of format from common lisp, and it has a vaguely similar feel to printf-style format strings, but it's a very different 'mini-language'

the jdk itself has whole libraries for formatting different kinds of strings, including internationalized date/time, currency, numbers, etc

I personally use cl-format out of (bad?) habit, and https://clojure.github.io/clojure/doc/clojure/pprint/CommonLispFormat.html gives a pretty good rationale for why it is useful even if you never used common lisp before

cl-format is lit but your coworkers might look at you funnily. Light years of any other formatter though. And much much faster - you don't want to use format anywhere where the performance is important.

Woah, how is cl-format faster? One would imagine the native one is faster. Also, how "equivalent" is cl-format with format in Common Lisp?

> Also, how "equivalent" is cl-format with format in Common Lisp? Claims to be 100% compatible. I personally haven't encountered any differences so far. > Woah, how is cl-format faster? Sorry, my memory got a bit hazy on this. In Common Lisp, format interprets and expands the control string at compile time. In Clojure, cl-format is a regular function, it's slower than Java's format. Just measured it – yeah, sorry, got it confused. I had to implement a home-grown precompilable string formatted for performance-sensitive things at work, I didn't use cl-format for that.

It’s not exactly 100% compatible — there are differences listed in the documentation above, and IME I dont think directives like tilde-slash are supported yet

What is "regular #date"? There's no built-in #date reader. And Java has more than one built-in date classes.

A quick look at the Tick's source code suggests that its date is just java.time.LocalDate. In many cases you can use it as is. And where you need to have e.g. java.util.Date or java.sql.Date, you'll have to figure out how exactly you want to convert between the two. It's not entirely straightforward and depends on your needs.

Thanks, I actually found something in the tick docs. What they are recommending is:

(-> tick-date .toInstant Date/from)

Hmm. LocalDate doesn't have a .toInstant member. So maybe I was wrong about LocalDate.

yeah, actually the docs don't say that - and it wouldn't work. this is a recipe for you:

(-> (t/date)
    (t/at "00:00")
    (t/in "UTC")
    (t/inst))
=> #inst"2023-08-02T00:00:00.000-00:00"

At the moment this is not supported, but you can add the deps referred to in the pom directly

You can up vote this kind of thing here https://ask.clojure.org/index.php/10892/add-support-for-bom-bill-of-materials-dependencies?show=10925#a10925

I recall that with some Locales it matters whether it's am vs AM and the same for pm/`PM`.

Weird, seems to work for me just fine on 18:

(let [formatter (java.time.format.DateTimeFormatter/ofPattern "M/d/uuuu h:mm:ss a")]
  (-> (java.time.ZonedDateTime/parse "10/13/2020 1:06:41 AM"
                                     (.withZone formatter
                                                (ZoneId/of "Europe/Helsinki")))
      .toInstant
      .toEpochMilli))
=> 1602540401000

there's two variants of ofPattern where one of them takes an explicit Locale and the other uses the system default. Depending on the default, it might accept AM or am

A while back we had a similar test fail on my machine because I happened to be using en_GB locale by default on my machine (while others used en or en_US etc)

> Depending on the default, it might accept AM or am Despite the fact that the TZ was later specified with .withZone, before the formatter was used?

Yeah, if I recall correctly. Or at least we fixed it by being explicit about it using the ofPattern(java.lang.String,java.util.Locale) constructor when creating the pattern.

Looking at the javadoc, I get the impression that the override zone is used wrt. zoned date(times) but the locale field affects how the specific texts and patterns are interpreted

https://borkdude.github.io/re-find.web/

generally, this is not really possible. you can read through docs on http://clojuredocs.org, or read clojure books (clojure for the brave and true, the joy of clojure, clojure applied), or read lots of clojure code to get exposed to the various functions in the core namespace (which is where the majority of clojure code comes from)

@U011LEAEURE this is really good! Thank you. @UEENNMX0T yeah, that'd be the other route, I just wanted to speed that up

The cheat sheet is also pretty decent: https://clojure.org/api/cheatsheet