SimpleDateFormat giving me different results (sometimes)

>29 Mar 29
What year is this? :)

What I mean (in case it is not clear) - fix your input string.
If this is here just for an example - then check what year their computers think it is :)

Oh yeah sorry about that, the input string is:

  Mon, 29 Mar 10 15:20:17 +0000

the users who are reporting the problem are saying their system times are set to:

  2010-03-29

which should be correct, yet on some systems that string is appearing as Tuesday instead of Monday, ugh.

Thanks

>> What happens if you switch to a four-digit year?

Where would I get a chance to do that though in the above code (that's all I'm doing, those three lines)? The devices are on mobile devices running Android, I guess it's possible they're somehow interpreting the "10" as 1910, but hmm - shoot how could I fix that? I don't have control over the initial input string, it's gonna be a 2 digit year and I'm stuck with that.

Thanks

~Considering that you mean java.util.Date I mean
And CPColin seem to have got to the same while I was typing and answering the door here :)

So it will be always 10 there?

Use another SimpleDateFormat to get from the String to Date. Correct the year. Then use the original one to get it back to string. But 10 will always be 1910 in Java I am afraid :(

Apparently SimpleDateFormat is supposed to handle the two-digit year parsing better than this. I agree with Venabili; use a SimpleDateFormat with a format string that matches your expected input to parse the date instead of the Date constructor that takes a String. That constructor is deprecated anyway.

Ok so yeah I'm stuck with the 2-digit year format, that's from a 3rd party service.

So I can do this:

  String input = "Mon, 29 Mar 10 15:20:17 +0000";

  SimpleDateFormat expected = "EEE, dd MMM yy HH:mm:ss Z";
  SimpleDateFormat  format = new SimpleDateFormat("E MMM d");
  String done = return format.format(expected.parse(input)));

so "expected" is the format that I'm getting the input in - but you're saying that will *always* be interpreted as 1910, right? I bet on some of these android devices, they implemented this a little different, because the majority of my users are reporting no problems, only a dozen or so are reporting the date being off by 1 day.

so the above is better, but I still need to correct the year, right? Ouch, so I basically have to override the year and set it to 2010. Argh!

Thanks

It *should not* be interpreted as 1910. The SimpleDateFormat javadocs say it should interpret it as 2010. I don't know if the Android implementation will follow that spec exactly.

From here:

http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html

"For parsing with the abbreviated year pattern ('y' or 'yy'), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created."

I would check if it is before 2000, just add 100... (so that this works next year as well) - as lon as you cannot get earlier dates. If just a few people report it, are you sure you get 10 from all of them? And if so - maybe different versions of JAva is installed on these (so that they hadnle 10 as 1910 and the rest as 2010)?

>CPColin,

But he is not using SimpleDateFormat now but new Date(string) and that's what interprets it as 1910 I suspect. :)

If he moves to two SimplteDateFormats it might get fixed automatically because it is supposed to. :) I would still put the check for <2000 (because of the androids and all)

Hmm ok so it's because I'm doing:

  new Date(input)

instead of:

  SimpleDateFormat expected = "EEE, dd MMM yy HH:mm:ss Z";
  Date date = expected.parse(input);

that I may be getting this weird behavior - because new Date() is using 1910 as the default, whereas using SDF should by default be using a date within the last 80 years of the current system time?

Thanks

That's how it is supposed to work anyway :)

If it is being run on different boxes they could be configured with different timzones which would give a different result.
If you want to explicitly use a particular timezone then specify it (as I explained in previous questions of yours)'

But if it is the timezone, they would be seeing "Tue 30 Mar" and not "Tue 29 Mar", right? Or what am I missing here - because I cannot see how the timezone change will change the day of the week but not the date...?

Yeah looks like not using the new Date() constructor works on those problem devices, thanks!

could be bad reports from users, you're not going to get the same date parsed as posted

Great :)