5 ms·

Or just use a long...

• Tharkun 10y ago
  Yeah. Have fun working out date arithmetic, leap seconds and time zones on your own. What could possibly go wrong.
  • kpil 10y ago
    No, that would be stupid - but you can't use a Date for that either.
    • Sharlin 10y ago
      You can; there are getters and setters for the different components. And because Date is lenient by default, you can do eg. date.setMonth(date.getMonth() + 1); and it will do the Right Thing even if the month is December.
      • jdmichal 10y ago
        The `get` and `set` methods on `Date` have been deprecated since 1.1... In favor of `Calendar`, which is all `Date` is using under the hood to perform such calculations anyway.
        • Sharlin 10y ago
          True that, somehow totally slipped from my mind. To my defense, the last few times I've used java.util.Date it has been with GWT which doesn't provide anything better at least out of the box.
          • jdmichal 10y ago
            No worries. The whole thing was a tire-fire from the get-go, and I certainly don't blame you.
  • bluestreak 10y ago
    It should be encouraged to use long. Not only it performs better, but it is also simpler to understand and use compared to obscurity of java.util.Date. I've written all of date arithmetic using only long values and I can share the code if anyone is interested
• adrianmsmith 10y ago
  Before Java 8 and Jodatime, it was better to use java.util.Date than a long, for type-checking and self-documentation. If a function accepts a java.util.Date and you pass an id of some database object by mistake, you'll get a compile error. If the function accepts a long you won't. If a function accepts a java.util.Date and the parameter is called "start" you know it accepts an instant in time, if it accepts a long you might think it could be something else. Yes, the class is terribly named, but before there was Java 8 and Jodatime, it was better to use it than a long.
  • phyzome 9y ago
    And rather importantly, with a dedicated type you're a bit less likely to encounter and off-by-a-thousand error when there's confusion about millis vs. seconds since Unix epoch.
  • bluestreak 10y ago
    It is not always a good idea to box primitives so that you can have compiler point out mistakes. Yes, it is good for developer once or twice, but end user will suffer performance hog forever.
    • nradov 10y ago
      Modern JVMs are pretty good at optimizing away the overhead of boxing primitives. So don't throw away the advantages of type checking unless you have hard evidence of an actual performance problem.
    • adrianmsmith 10y ago
      This is a trade-off between "should the program work" or "should the program be fast". The users would prefer a slow program that works, over a program that crashes or corrupts data.
  • nrinaudo 10y ago
    But java.util.Date is mutable where a long isn't, and that's a problem. People can mutate a Date from under your feet if they manage to get a reference to it. This has a lot of far reaching implications, but essentially, unless you protectively copy all values of type Date you get or give, you can't trust your own internal state. You can't write a legal equals or hashCode implementation that uses a date field. The list goes on. Don't do java.util.Date.
• hn_throwaway_99 10y ago
  It would usually be better to use an Instant ( https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html https://docs.oracle.com/javase/8/docs/api/java/time/Instant.... ), which helps make your code self-documenting and provides a whole set of methods to deal with the fact that your long actually represents a point in time along a timeline.