Comment by filoeleven | Hacker News Reader

Comment by filoeleven | Hacker News Reader

Parent Full thread

The “keep readability in mind” tip exposes more Java/OOP icebergs.

  var date = LocalDate.parse("2019-08-13");
  var dayOfWeek = date.getDayOfWeek();
  var dayOfMonth = date.getDayOfMonth();

> The first one is pretty intuitive, the parse method returns a LocalDate object. However, for the next two, you should be a little bit more familiar with the API: dayOfWeek returns a java.time.DayOfWeek, while dayOfMonth simply returns an int.

Java.time.dayOfWeek takes a TextStyle and a Locale, both of which have a list of properties and methods I have to read all about before using. dayOfMonth returns an int, and I can see if it’s 0- or 1-indexed then do what I want with it from there. Why does DayOfWeek have a class instead of being a function that I can throw a number at like dayOfMonth?

I’m also skeptical about Java.LocalDate being “pretty intuitive,” having worked on local vs server vs data-store timestamps, as most of us have. At least LocalDate doesn’t have mutable setter methods like other Java dates…

>Why does DayOfWeek have a class instead...

B/c in most of the world, the 1st day of the week is Monday, unlike the US where it happens to be Sunday. Having it enum is a pretty decent choice.

Sure, someone’s got to make a numbering choice somewhere for the canonical value. Same thing goes for timestamps, and we settled on UTC, so all offsets can be calculated given that.

Once you know that “Java says X is the first day of the week,” you can make your own calculations from it with modulo arithmetic. There is no need for a class here, or for it to build a whole subsystem of locale interpretations. That should be the responsibility of a library. Maybe even the standard library, but it should not mask the core data values in the system by default.

dayOfWeek(n) should be something that you apply to a value, not something that returns a value with no args based on your locale. Or, if it does, the function itself should accept an override locale instead of assuming it from a higher level.

Timestamps are hard and maybe not the best example. It was what’s in the article though, and I’m also pretty salty about them after some recent work stuff.

> Once you know that “Java says X is the first day of the week,”

The basic assumption when designing anything is that you can never rely on assuming that other humans "will" know.

A funny part is that java has java.util.Calendar that has setFirstDayOfWeek(int), the default depends on the locale used to create the Calendar. It's considered a bad design overall, esp with SUNDAY const being 1. For most of the world that (sun=1) made absolutely no sense at all and assumed one of those weird things like jokes about IQ and room temperature.

> java.util.Calendar that has setFirstDayOfWeek(int), the default depends on the locale used to create the Calendar

That is exactly the kind of hidden assumption that I’m trying to fight against! If the date and the locale were both passed in as parameters, preferably just plain data, this would be a transparent function. Instead, you have to find and read through the documentation to see what kind of mischief is going on. And you have to do that every time you encounter a Java.until.Calendar.

Edit to clarify: if “locale” is some class, you have to learn that class DSL to examine it, and depend on a runtime debugger that does the same. If “locale” is just a hash map, you can examine the values without a lot of faff.

Sure, but how far does that go?

If I try to assign an int value to “3.2” will the language silently fail with null, or a round, or a floor, or a ceiling? Some level of understanding is necessary. I want it to also be reasonably explicit.

Java time library doesn’t meet that standard until Instant.

> If I try to assign an int value to “3.2” will the language silently fail with null, or a round, or a floor, or a ceiling?

one may argue that the only correct thing to do here is a compile-time error

Because dates are actually complicated, and so is the real world. You may be content in having just an int to display Sun 24-10-2021 to your users, but there are needs to get the actual weekday. From locale differences (US has the start of week on Sunday, most of the world on Monday), to locale differences (Country X nuked 43 days on year Y, your basic algorithm doesn't handle that because it's not working with tz-data, and it's broken now), to locale differences (how do you plan on displaying it? Short form? Translated?), to infinitely more date fuckeries that _have_ to be handled if you want your Date API to be credible.

Yeah. See my reply to your sibling comment: timestamps suck and it was maybe a foolhardy example that I’m not competent enough to defend. Here goes me trying to make my case anyway! =)

My big assumption is that if a system cares about global timestamps, it should go all the way. If you have a “canonical system timestamp,” which I think is necessary, then you can operate on it functionally to get whatever local display that you need out of it. Your example with Country X means that dayOfWeek() AND dayOfMonth() are already both broken unless/until the language itself makes an emergency update to account for the change.

With dayOfMonth() I could substitute another function that handles the change. With dayOfWeek() I’d have to override the whole class, if possible.

I have seen this in action. A company I worked for was stuck with using outdated time libraries in Java because of IBM WebSphere (1.7? 1.8?). Those didn’t match the more recent libraries in Javascript (moment.js) and the differences caused significant problems, since the same locale keys had different time offsets.

Why are you blaming a class called “LocalDate” for not giving you global timestamps? The java doc for the class has an entire paragraph on how it is not a time. If you want to model a specific instant in time, use Instant.

This is a fair criticism. Java Instant should be the standard, and anything that doesn’t use it as its base should be deprecated. I have to support older JDKs, so I don’t know. The article starts with Java 9, and Instant was included with 8, so it is not a fault of the article.

I’ll gladly grant that the mutable date types of pre-jdk8 Java were ugly APIs, but you’re still missing my point here: the LocalDate class was added in the same release as Instant was—it’s not a worse Instant, it’s solving a different problem.

I guess what I’m aiming for (and perhaps not hitting the mark with) is that LocalDate’s 9 static constructors should be reduced to a single constructor that takes an Instant. If Instant does some translation from “whatever -> Instant”, it should do all the translation.

If you want something like a birthday, you’re already making assumptions about the beginning and end of that day. Ask a 21-year old from Australia about getting into USA bars on their birthday. It’s a system-specific decision on how to handle those things. Probably more relevant to finance, but the underlying principle is the same: dates without timestamps are ultimately derived from or interpreted with dates with timestamps, and hiding that fact too early in an API (like LocalDate might do) is a bad abstraction.

The whole point of a local date is that it is just a container for three values - year, month and day, and nothing more than that. You cannot go from `Instant` to `LocalDate` without specifying time zone/offset information, and vice versa.

“Local date” is a useful concept on its own, and it is not at all always derived from an absolute instant of time. Some examples:

1. Date in a file/directory name, which often happens with big data processing. There is no way to tie these dates to some absolute frame of reference without external information, but it is often not really necessary, and there is still a need to work with these values as dates, e.g. compare them or compute offsets.

2. Anything which is tied to the user’s local time frame, e.g. alarms. They simply cannot be tied to some absolute time reference, because they always represent some time wherever the user is located right now. Even birthday is something like this, because for the purposes of celebration, people care about the specific calendar day, not the actual moment of time in whatever absolute time scale there is (at least, most of the people I know think like that!)

Reply on news.ycombinator.com