Java Date

[John Paterson]

Hi Folks

I have these lines of code

SimpleDateFormat sdf = new SimpleDateFormat("dd-MM-yyyy hh:mm:ss");
java.util.Date _startDate = sdf.parse("01-12-2014  14:01:00");

The problem is when I make a call to another method like this:

someobject.method(new Date(_startDate.getTime()));

I am getting a java.lang.NumberFormatException: null

I am not sure why I am getting this, hope someone can advise. Thanks.

[Ulf Dittmer]

Please post an SSCCE (<-- that's a link) that demonstrates the issue. I think we need more context to investigate.

[Campbell Ritchie]

Stop using Date. Use the Java8 classes instead.

[Prabhakar Reddy Bokka]

The code you posted works perfectly.. seems the problem is somewhere else in your code. Check if you are assigning the value properly.

[Ulf Dittmer]

Stop using Date. Use the Java8 classes instead.

... assuming using Java 8 is feasible. In many environments it's not (yet) an option.

[Prabhakar Reddy Bokka]

Campbell Ritchie wrote:Stop using Date. Use the Java8 classes instead.

Not sure how many applications are upgraded to java8. Many applications are still using java 5/6. Practically this may not be possible if your application using lower version of java.

[Maneesh Godbole]

Ulf Dittmer wrote:

Stop using Date. Use the Java8 classes instead.

... assuming using Java 8 is feasible. In many environments it's not (yet) an option.

Indeed! Sometimes it is frustrating to see how slowly environments upgrade their min version

[Ulf Dittmer]

Practically this may not be possible if your application using lower version of java.

That brings us back to my first post, then. Post a complete, compilable example that demonstrates the problem.

[Campbell Ritchie]

Ulf Dittmer wrote: . . .
... assuming using Java 8 is feasible. In many environments it's not (yet) an option.

In which case you would use Joda Time. That looks very similar to the Java8 classes. I think Java8 probably simply imported Joda Time.

[Ulf Dittmer]

In which case you would use Joda Time

I don't think that it is good advice for someone who has a problem with API X to use API Y instead. The first step is to figure *why* there is a problem with API X. Only then -and after knowing a good deal more about the situation than we know now- can a recommendation to use API Y make sense. Any possibly not even then.

[Jesper de Jong]

Your mistake is in the format string: "dd-MM-yyyy hh:mm:ss"

Note that "hh" stands for hours, but in 12-hour clock format (hours 1 - 12).

Looking at the date string you are trying to parse, you actually want "HH" instead of "hh" - "HH" is 24-hour clock (hours 0 - 23).

So. change the format string to this: "dd-MM-yyyy HH:mm:ss"

[Winston Gutkowski]

Ulf Dittmer wrote:I don't think that it is good advice for someone who has a problem with API X to use API Y instead. The first step is to figure *why* there is a problem with API X. Only then -and after knowing a good deal more about the situation than we know now- can a recommendation to use API Y make sense. Any possibly not even then.

In general, I'd agree with you; but Java's date/time API is so bad (particularly Calendar) that it has pretty much always needed an alternative - and before version 8, that was Joda time. And I say that as someone who loves the language.

Example: I've been using Java for 13 years, and I still don't know all the ramifications of clear()ing a Calendar field - at least not ALL of the 16 that you can clear(); not to mention the 22 or more (out of a total of 54) that it might affect.

Calendar is just a horrible interface, and I echo Maneesh's words about why it's taken so darn long to replace it.

Winston

[Campbell Ritchie]

I think you are both right, Ulf and Winston. Sorry for confusing things.

[Ulf Dittmer]

Winston Gutkowski wrote:Calendar is just a horrible interface

I agree, which is why I use java.util.Date to this day if no time zone and DST support is required, and why I initially created https://coderanch.com/how-to/java/JavaDatesFaq to teach people how to make do without using Calendar if possible.