• bvs23bkv33 (unregistered)

    JSO-310? really?

  • DQ (unregistered)

    TRWTF is including a link in an article that doesn't work...

  • seebs (unregistered)

    I'm just so amused to see the name "getParamValue" again. It brings back memories. I saw that once in an early C++ (pre-STL) system. The beautiful part was that putParamValue stored into the same part of the object for any value type except "void *", which got handled completely differently.

  • jd (unregistered)

    Umm, there is an 'ofInstant' method actually in LocalDateTime object - https://docs.oracle.com/javase/10/docs/api/java/time/LocalDateTime.html#ofInstant(java.time.Instant,java.time.ZoneId) . The reason why timezone offset is being passed as well is because you're trying to convert a point in time into local (i.e. timezone-agnostic) date and time. To do that, you need to say in which timezone you 'are' (as instant itself is TZ-agnostic) - the same point in time will yield different 'local' datetime for New York and different for London. Still it should not look like that.

  • jd (unregistered)

    Umm, there is an 'ofInstant' method actually in LocalDateTime object - https://docs.oracle.com/javase/10/docs/api/java/time/LocalDateTime.html#ofInstant(java.time.Instant,java.time.ZoneId) . The reason why timezone offset is being passed as well is because you're trying to convert a point in time into local (i.e. timezone-agnostic) date and time. To do that, you need to say in which timezone you 'are' (as instant itself is TZ-agnostic) - the same point in time will yield different 'local' datetime for New York and different for London. And Timestamp class specifically accepts LocalDateTime, and not Instant, as it's a class to represent SQL timestamp (which according to ANSI standard is not a point in time, but rather a date and time combined, potentially without timezone info - https://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements003.htm). Also the parsing from ISO instant format to local date would fail, as the result depends on the chosen timezone offset at which one wants to look at it.

  • Rob (unregistered)

    There are two mistakes in this article:

    1. Timestamp isn't new, it isn't immutable and it isn't part of JSR-310. It's part of the java.sql package and has been available since Java 1.1 (see https://docs.oracle.com/en/java/javase/13/docs/api/java.sql/java/sql/Timestamp.html). It extends java.util.Date so it's just as bad. Unfortunately, it's what's used when working with databases.

    2. LocalDate has an ofInstant method that's been available since Java 9: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/time/LocalDate.html#ofInstant(java.time.Instant,java.time.ZoneId). However, this isn't what's used in this article - that's LocalDateTime.ofInstant, which has been available since the introduction of LocalDateTime: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/time/LocalDateTime.html#ofInstant(java.time.Instant,java.time.ZoneId).

    And there is a reason why there is a timezone here. To convert an instant (which is a number of seconds plus nanoseconds since the epoch, to a LocalDateTime, you need to know where that LocalDateTime is. An instant of "now" could be 2019-12-16T15:00 in one part of the world but 2019-12-16T09:00 in another. The timezone will help with figuring out what the actual value should be.

    The end conclusion is still valid though, this code is overly complex and unnecessary.

  • (nodebb)

    It all comes down to this: Date-Time stuff is difficult. Most of the time there ARE routines in your language of choice available. Please use them.

  • Wizofaus (unregistered)

    DateTime stuff is really only hard because of silly human/political conventions, like always performing some operation at 3am local time, even though what exact point in time that is from place to place or year to year varies in no predictable fashion.

  • (nodebb)

    I've only used dates in Java once, and that was to write a JDBC driver for a database product (because the one supplied was terrible). Naturally neither java.util.Date nor java.sql.Date were up to the job...

  • Simon (unregistered)

    Yeah, agreed with Rob and JD. This looks like someone has a string date/time in UTC, and needs to convert it to the local time zone before storing it zone-less in the database. The code isn't optimal — it could be simplified by using the Instant.parse() method to parse the string directly as suggested — but this is otherwise about as simple as it gets... three steps, 1) parse string to UTC, 2) convert UTC to local time, and 3) convert local to the Timestamp class needed by the database.

    What is needed is a more descriptive method name, and maybe some comments that make the intention clear without forcing the reader to figure it out from experience.

Leave a comment on “An Advent Calendar”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article