Hacker News Reader

Comment by ohgodplsno | Hacker News Reader

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.

View on HN

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