Bug?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug?

Nils Kilden-Pedersen
I just got bitten by this:

LocalDate date = new LocalDate(System.getProperty("date"));

I changed from a String to LocalDate to insure type safety.

But we had some old code doing this:

java -Ddate=20110503

And it didn't fail because that date is apparently a valid year and LocalDate parsing just makes up whatever it's missing. I assume that's considered lenient parsing.

So LocalDate became this:

"20110503-01-01"

Which of course is a valid date, just not the date I wanted. 

If it's not a bug, I think it should be. I can't see any good reason why a particular type, on parsing, should accept incomplete input. If this is what I wanted, I should have done this:

LocalDate date = Years.parseYears(years).toLocalDate 

If that existed that is.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug?

jodastephen
So, as the javadoc says, it uses localDateParser() which can parse
just the year,

I think I'd call it "non-ideal" rather than a bug. Changing it would
have knock on effects elsewhere with backwards compatibility issues,
so won't be done.

Stephen


On 30 June 2012 17:40, Nils Kilden-Pedersen <[hidden email]> wrote:

> I just got bitten by this:
>
> LocalDate date = new LocalDate(System.getProperty("date"));
>
> I changed from a String to LocalDate to insure type safety.
>
> But we had some old code doing this:
>
> java -Ddate=20110503
>
> And it didn't fail because that date is apparently a valid year and
> LocalDate parsing just makes up whatever it's missing. I assume that's
> considered lenient parsing.
>
> So LocalDate became this:
>
> "20110503-01-01"
>
> Which of course is a valid date, just not the date I wanted.
>
> If it's not a bug, I think it should be. I can't see any good reason why a
> particular type, on parsing, should accept incomplete input. If this is what
> I wanted, I should have done this:
>
> LocalDate date = Years.parseYears(years).toLocalDate
>
> If that existed that is.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...