• Fristator (unregistered)

    I really like the frist implementation!

  • (nodebb)

    As a variable name, criterias made my eyes bleed. Imagine talking about any more conventional noun in the plurally-plural form, like bookses, bureauxes, elephantses. Well, "criterias" is like that.

    Pro-tip: one criterion, two (or more) criteria.

  • Conradus (unregistered) in reply to Steve_The_Cynic

    I've got criterias in my pocketses!

  • (nodebb) in reply to Conradus

    ... and a magic ringses, Precious!

  • (nodebb)

    ... and a magic ringses, Precious!

    You took the wordses right out of my mouthses

  • (nodebb) in reply to Steve_The_Cynic

    Clearly Gollum was the original author and did this for the "Hobbitses".

  • EzTz (unregistered)

    I could write a book on date (and especially timezone) WTFs I've seen over the years. In the early aughts I worked on restaurant reservation software. We 1) hardcoded daylight savings time dates, and 2) assumed timezones are always 1 hour apart, because the visionaries that owned the company didn't see how they would ever be wrong, even when presented with documentation to the contrary. Then March 2007 happened. For 2 glorious weeks all hell broke loose. After that we were told to implement real timezone and DST handling.

  • (nodebb)

    That it works is what makes me hate it, honestly.

    Amen, brother . . . amen.

  • Rob (unregistered)

    Even without converting to LocalDate this could be done much simpler using Comparator.comparingInt(LocalDateTime::getYear).thenComparingInt(LocalDateTime::getMonthValue).thenComparingInt(LocalDateTime::getDayOfMonth).

  • Officer Johnny Holzkopf (unregistered) in reply to Steve_The_Cynic

    But my LCD display shows "criteriases" is correct when I press the foot pedal!

  • Java Apologist (unregistered)

    Obviously it's pointless and can be replaced by a one-liner, but this code actually looks pretty clear, aside from the ugly nested generic.

    I can't imagine why you'd want this function, though. If it's the input for a sort() or max() or something, then you have obvious bugs from discarding the time information. For anything else, you'd probably just want to check if the date parts are equal.

  • Wendy (unregistered)

    Yet another example of a programmer reimplmenting something in a library, badly (or at least wastefully).

    I blame the size of teh libraries - roo many routines, many duplicating each other with trivial variations. There is now too much material!@

  • Dateless (unregistered)

    Not many programmers get dates

  • Ex-Java Dev (unregistered)

    Now, it's been a few years, but while I definitely appreciate the simplicity of the new code, and would prefer the old code written differently, they DON'T do the same thing!

    The old code naturally discards the 'time' component of the 'LocalDateTime', matching solely on the DATE.

    With the replacement, you can get 2025-09-15T01:00:0001 being greater than 2025-09-15T01:00:0000, even though the business logic wants them equivalent.

  • (nodebb)

    They possibly assumed that all DateTime classes are represented as 64-bit numbers, and first thought they'd get the number representation of both dates and return one minus the other. But before they got stuck into that approach, they realised there could be some overflow issues if the dates are far enough apart, and also didn't want to include the time information. And so came up with this, because why RTFM?

  • Ginssuart (unregistered)

    I once came across a piece of code where dates were handled as six separate strings: year1, month1, day1, and year2, month2, day2. These strings were then parsed to integers, but without any sanity checks or exception handling. As a result, a value like "1337" for the day would have been considered valid, while "13.37" would have caused the program to crash.

    After that, the code multiplied the year by 10000, the month by 100, and left the day unchanged. These values were then added together to create a single number representing each date, and the results were compared. The function returned -1, 0 or 1 depending on whether the first date was earlier, the same, or later than the second.

    However, due to the missing validation, a date like ("16", "9", "2025") and ("116", "8", "2025") ended up being considered equal.

    When I left the company, this code was still running in production.

  • ignorabimus (unregistered)

    Unfamiliar with Java, does the .compareTo rewrite already do the "rounding to the day" part?

  • GreatGobo (unregistered) in reply to ignorabimus

    the .toLocalDate strips the time part

  • matt (unregistered)

    We're all having a good laugh at criterias, but tut tut Remy on "preceeds".

Leave a comment on “Functionally, a Date”

Log In or post as a guest

Replying to comment #684404:

Log Out

« Return to Article