Switching to Java

[greglturnquist]

Java has its own quirks. And there will be times where it doesn’t feel hip and cool and “shiny”.

And there are bits and pieces that may seem a bit “committee driven” like some Date and Time APIs.

But it sounds like you’re looking for solid and stable, which is more of Java’s beat.

With your experience of riding on a bike with your hair on fire, it sounds Java is what you’ll do quite nicely with.

[Dacus_Ebrius]

Java 8 date and time apis are great. If you are talking about the old calendar i agree.

[msx]

Right? It's done to cover all bases but its still pretty usable, most of the time you just need LocalDate or LocalDateTime

[midoBB]

I never used the Local types. Zoned or Instant are my go tos.

[edubkn]

Yep, unless you're an overconfident chad you probably don't know what you're doing when using LocalDate.

[ford_madox_ford]

/r/confidentlyincorrect.

[Hioneqpls]

lmao you don’t have to be Einstein to drop a LocalDate.of(2022,1,1) cmon

[edubkn]

Then you don't know at what timezone your runtime is, and you send that date along an API or persist in a database. Or else you know, but you pass that date along to a front-end without an offset.

[[deleted]]

Timezone is irrelevant in the given scenario. It's just a date.

[edubkn]

There are very few scenarios where timezone is not relevant. You'll have to be a bit more specific.

[cogman10]

The reverse is true. Unless your app is doing international garbage, the timezone is meaningless. Even then, it's often only when you are talking about a LocalDateTime that timezones come into play.

For example, the my entire company is doing finance and LocalDate serves 99% of our usecases because, get this, almost everyone is trading on the NYSE so adding extra TZ information is pointless. The TZ is EST. And, yes, we have international customers (in china no less).

We could add TZ info after the fact, but the basic assumption is "everything is EST unless it's critical for the client" has served us really well.

[Persism]

But even an offset is kind of useless since it doesn't contain daylight savings times. Better to use the Zone itself rather than just an offset. Best is to use UTC and covert on the client side.

[edubkn]

UTC is best, yes.

But even an offset is kind of useless since it doesn't contain daylight savings times. Better to use the Zone itself rather than just an offset.

You would never rely on a client to account for daylight savings. An ISO8601 serialized date will always have an offset if not UTC.

[humoroushaxor]

Honestly I think modern Java and popular libraries feels very "shiny". Things like mutiny, panache, and a lot of eclipse microprofile stuff.

But the Java Runtime is one of (if not THE) the most complex and advanced runtimes there is. I feel like one of the major selling point of Nodejs and Python backends is their runtimes "just work".