6 ms·

The “keep readability in mind” tip exposes more Java/OOP icebergs. var date = LocalDate.parse("2019-08-13"); var dayOfWeek = date.getDayOfWeek(); var day

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…

xxs 5y ago
>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.
- filoeleven 5y ago
  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.
  - jcelerier 5y ago
    > 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.
    - xxs 5y ago
      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.
      - filoeleven 5y ago
        > 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.
    - filoeleven 5y ago
      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.
      - jcelerier 5y ago
        > 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
ohgodplsno 5y ago
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.
- filoeleven 5y ago
  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.
  - riwsky 5y ago
    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.
    - filoeleven 5y ago
      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.

xxs 5y ago

>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.

filoeleven 5y ago
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.
- jcelerier 5y ago
  > 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.
  - xxs 5y ago
    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.
    - filoeleven 5y ago
      > 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.
  - filoeleven 5y ago
    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.
    - jcelerier 5y ago
      > 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

ohgodplsno 5y ago

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.

filoeleven 5y ago
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.
- riwsky 5y ago
  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.
  - filoeleven 5y ago
    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.