Java SimpleDateFormat parsing irregularities - java

I'm doing some date parsing in Java and am encountering some weird behavior.
I have a date string such as follows:
String s = "Sun Aug 11 2013 11:00:00 -0700 (Pacific Daylight Time)"
I'm trying to parse it into a date object like so:
SimpleDateFormat sdf = new SimpleDateFormat("EEE MMM dd yyyy HH:mm:ss Z (zzzz)");
I then print out the resulting date object from sdf.parse(s) and get:
Sun Aug 11 12:00:00 CDT 2013
I am in the central time zone, so it makes sense that it prints it as such, however, CDT is -0500, so the parsed date should be 13:00, not 12:00.
The odd thing is, if I remove either of the redundant pieces of time zone information, the date parses correctly. Using the format "EEE MMM dd yyyy HH:mm:ss Z ('Pacific Daylight Time')" or the format "EEE MMM dd yyyy HH:mm:ss '-0700' (zzzz)" results in the correct date:
Sun Aug 11 13:00:00 CDT 2013
This behavior seems to only occur with dates that fall within daylight savings time. If I instead parse a date in, say, December, with my initial date format, I get the correct result.
I have somewhat limited control over the format of the dates I'm parsing, and they could be coming from a variety of time zones. Has anyone encountered this behavior before, and is there a way to get around it without changing the format of the date string? I realize the time zone designations are redundant, but they aren't incorrect as far as I can tell.

There have certainly been bugs in Java's handling of daylight saving time and time zones in the past, and this sure looks like one you've found. What version of Java is this?
You might want to try giving Joda-Time a try to see if it handles the given date correctly.
If Joda doesn't help, you might need to try pre-parsing some of that date string to remove the descriptive time zone in parenthesis since it works when only one is defined. Very strange indeed!

Related

Why does the LocalDateTime conversion to java.util.Date is shifting for very old date?

I am having trouble with converting old dates from java.time.LocalDateTime to java.util.Date
I tried a lot of variation and it still has the same shifted dates. I would assume that it is some weird calendar performed but it is failing.
Date to parse 1800-01-01 00:00:00
I used a very simple convert function.
Date.from(ldt.atZone(ZoneId.systemDefault()).toInstant());
TimeZone
a.Converted via SimpleDateFormat
b.Converted via DateFormatter to LocalDateTime to java.util.Date
Asia/Tokyo
1800-01-01 00:00:00 JST
1799-12-31 23:41:01 JST
Europe/Brussels
1800-01-01 00:00:00 CET
1800-01-01 00:04:30 CET
Australia/Sydney
1800-01-01 00:00:00 AEST
1799-12-31 23:55:08 AEST
UTC
1800-01-01 00:00:00 UTC
1800-01-01 00:00:00 UTC
a. Convert String to java.util.Date via SimpleDateFormat
b. Convert String to java.time.LocalDatetime via DateFormatter, then convert it to java.util.Date
Now I see it only works for the UTC timezone, I cannot just change the software timezone as it will mess with the others. Anyone know any other way to convert a java.time.LocalDateTime to java.util.Date for an old day?
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
===== following is added after sweeper's answer to illustrate it is not for all ====
The curious thing is it only happens to really old dates, it does not happen to 1900-01-01 00:00:00 but have not check yet at which point the trouble started. I was thinking that maybe because of and adjustment / change at some point in 18XX year.
System.out.println(ZoneId.of("Asia/Tokyo").getRules().getOffset(LocalDateTime.parse("1800-01-01T00:00:00")));
SimpleDateFormat format1 = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
System.out.println(TimeZone.getTimeZone("Asia/Tokyo").getOffset(format1.parse("1800-01-01T00:00:00").getTime()));
System.out.println(ZoneId.of("Asia/Tokyo").getRules().getOffset(LocalDateTime.parse("1900-01-01T00:00:00")));
SimpleDateFormat format2 = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
System.out.println(TimeZone.getTimeZone("Asia/Tokyo").getOffset(format2.parse("1900-01-01T00:00:00").getTime()));
Results to
+09:18:59
32400000
+09:00
32400000
Similar to this question, the old API disagrees with ZoneId.systemDefault() about what offsets those locations should be at on the date 1800-01-01.
You can see this in action:
System.out.println(ZoneId.of("Asia/Tokyo").getRules().getOffset(LocalDateTime.parse("1800-01-01T00:00:00")));
var format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
System.out.println(TimeZone.getTimeZone("Asia/Tokyo").getOffset(format.parse("1800-01-01T00:00:00").getTime()));
Output:
+09:18:59
32400000
As said in the linked post, +09:18:59 is the Local Mean Time in Japan, and 32400000ms is exactly 9 hours. This is because the old APIs don't support Local Mean Time. Note that Japan standardised their timezones in 1888, which explains why the outputs from the two APIs are consistent for 1900-01-01.
So ZoneId thinks the offset of Asia/Tokyo is 18 minutes and 59 seconds more than what TimeZone (which is used by SimpleSateFormat and Date.toString and so on) thinks it is.
This is exactly why there is a "shift" in the output. ldt.atZone(...) generates
1800-01-01T00:00:00+09:18:59
and toInstant turns this into an instant.
Assuming you are using Date.toString or some other old API that uses TimeZone to generate the string, the old API would think this instant is at +09:00:00 instead! What is the above date at +09:00:00? Well, just subtract the 18 minutes and 59 seconds (just like how you would subtract 9 hours to convert a UTC+9 date to UTC+0)!
And that's how you get:
1799-12-31 23:41:01
As for solutions, there really is nothing wrong with the "shifted" Date that you got. If you just convert it back to a ZonedDateTime and format it with DateTimeFormatter for display, everything should work as normal. In fact, if you can, consider not converting to Date at all, and use Instants instead.
If you cannot do that, I would suggest that you should not mix the two APIs.

Java - parse date with AM/PM next to seconds (no space)

I am trying to parse the following kind of date: Dec 12 2001 11:59:59PM.
If the AM/PM wasn't next to the seconds, I would use the following pattern: MMM dd yyyy HH:mm:ss a.
However the AM/PM is ignored with the pattern MMM dd yyyy HH:mm:ssa (and is therefore always interpreted as AM).
I am trying to use a SimpleDateFormat. I tried to specify a locale to no avail.
Is this possible using a SimpleDateFormat or do I need to use an alternative method/external processing? The SimpleDateFormat particularly interests me due to its use in the pattern attribute of the #JsonFormat annotation.
Thanks.
I would like to use java.time API from Java8+ instead of the old Date :
String date = LocalDateTime.now().format(
DateTimeFormatter.ofPattern("MMM dd yyyy hh:mm:ssa", Locale.ENGLISH)
);
or :
DateTimeFormatter format = DateTimeFormatter.ofPattern(
"MMM dd yyyy hh:mm:ssa", Locale.ENGLISH
);
String date = LocalDateTime.of(2001, Month.DECEMBER, 12, 11, 59, 59).format(format);
Outputs
Jun 14 2018 03:01:02PM
Dec 12 2001 11:59:59AM
with AM/PM you want 12 hours hh instead of 24 hours HH.
hh:mm:ss''a
As k/K/h/H influence a too, now everything might work with ssa.
If ssa is still problematic (seemingly a bug), try separating the letters by an empty literal string (single quotes).
The following works:
hh:mm:ssa
It may very well be possible with SimpleDateFormat, but you will probably prefer to use java.time, the modern Java date and time API:
DateTimeFormatter formatter
= DateTimeFormatter.ofPattern("MMM dd uuuu hh:mm:ssa", Locale.ENGLISH);
String dateTimeString = "Dec 12 2001 11:59:59PM";
LocalDateTime dateTime = LocalDateTime.parse(dateTimeString, formatter);
System.out.println(dateTime);
Output:
2001-12-12T23:59:59
As others have said, your problem was not with the lack of a space between seconds and AM/PM marker, but with using uppercase HH for the hours. Uppercase HH is for hour of day from 00 through 23, where what you wanted was lowercase hh for hour within AM or PM from 01 through 12.
And as yet others have said, there are issues with using SimpleDateFormat and its friend Date:
Those classes are long outdated.
Those classes are poorly designed, and SimpleDateFormat in particular is renowned for being troublesome. Your experience is typical and certainly not unusual.
Getting a correct result from SimpleDateFormat requires that either the JVM time zone setting agrees with the time zone understood in the string, or you set the time zone of the SimpleDateFormat to the relevant time zone. The former is hard to guarantee since the time zone setting can be changed any time from another part of your program or from other programs running in the same JVM.
This also means that if you do require an instance of the outdated Date class (for example for a legacy API that you don’t want to change just now), you will need to decide on a time zone for the conversion. Then convert for example like this:
Instant inst = dateTime.atZone(ZoneId.of("America/Metlakatla")).toInstant();
Date oldfashionedDate = Date.from(inst);
System.out.println(oldfashionedDate);
I hesitate to show you the output because Date shows a quite surprising behaviour here.
Thu Dec 13 08:59:59 CET 2001
08:59? On December 13? The conversion has given you the correct point in time. When I print the Date, its toString method is invoked. This in turn uses my JVM’s time zone setting for producing the string, so the output is in a completely different time zone from the one where the conversion happened. So apparently when it’s 23:59 in Metlakatla, it’s already 08:59 the next day in Copenhagen (my time zone; CET in the output is for Central European Time). Had my JVM’s time zone setting been America/Metlakatla too, the output would have agreed more with the expected:
Wed Dec 12 23:59:59 AKST 2001
java.time is more helpful
What you asked SimpleDateFormat to do was to parse a time that had hour of day 11 and PM. This is really self contradictory since PM only begins at hour of day 12. So it would be reasonable to expect an exception from the request. A SimpleDateFormat with standard settings doesn’t give you that. It’s very typical for SimpleDateFOrmat to give you a wrong result and pretend all is well. However let’s for a moment try my modern code with your format pattern string of MMM dd yyyy HH:mm:ssa. Then we get:
Exception in thread "main" java.time.format.DateTimeParseException:
Text 'Dec 12 2001 11:59:59PM' could not be parsed: Conflict found:
Field AmPmOfDay 0 differs from AmPmOfDay 1 derived from 11:59:59
I don’t claim I understand exactly why it is worded like this, but it is mentioning a conflict in the AM/PM, which is exactly what we have.
PS
I hadn’t thought at first that I’d contribute an answer, but in the end I was provoked by on one hand bohemian’s comment that only Joop Eggen’s answer was correct and on the other hand a couple of comments by Basil Bourque claiming that you could not use the SimpleDateFormat that Joop Eggen was using. So I wanted to set things straight.
Link
Oracle tutorial: Date Time explaining how to use java.time.
Java internally uses the builder pattern. This is slightly modified from the source code of DateTimeFormatter.RFC_1123_DATE_TIME:
I don't recommend using this over the alternative, DateTimeFormatter.ofPattern(), but it can prove more powerful in certain scenarios where you hit the limitations of ofPattern.
Map<Long, String> moy = new HashMap<>();
moy.put(1L, "Jan"); moy.put(2L, "Feb"); moy.put(3L, "Mar");
moy.put(4L, "Apr"); moy.put(5L, "May"); moy.put(6L, "Jun");
moy.put(7L, "Jul"); moy.put(8L, "Aug"); moy.put(9L, "Sep");
moy.put(10L, "Oct"); moy.put(11L, "Nov"); moy.put(12L, "Dec");
DateTimeFormatter format = new DateTimeFormatterBuilder()
.appendText(MONTH_OF_YEAR, moy)
.appendLiteral(' ')
.appendValue(DAY_OF_MONTH, 2)
.appendLiteral(' ')
.appendValue(YEAR, 4, 4, EXCEEDS_PAD)
.appendLiteral(' ')
.appendValue(HOUR_OF_AMPM, 1, 2, NOT_NEGATIVE)
.appendLiteral(':')
.appendValue(MINUTE_OF_HOUR, 1, 2, NOT_NEGATIVE)
.optionalStart()
.appendLiteral(':')
.appendValue(SECOND_OF_MINUTE, 1, 2, NOT_NEGATIVE)
.optionalEnd()
.appendText(AMPM_OF_DAY)
.toFormatter();
System.out.println(format.parse("Jun 14 2018 2:51:22AM")); // {},ISO resolved to 2018-06-14T02:51:22
System.out.println(format.parse("Jun 14 2018 2:51:22PM")); // {},ISO resolved to 2018-06-14T14:51:22
Note
Unfortunately, the below code is inaccurate. AM/PM marker is never read. Depending on the local time, either AM or PM is assumed.
Original answer
Use the following format string "MMM dd yyyy HH:mm:ssaaa".
String str = "Jun 14 2018 13:53:19PM";
DateFormat df = new SimpleDateFormat("MMM dd yyyy HH:mm:ssaaa");
try {
Date date = df.parse(str);
System.out.print(df.format(date));
} catch (ParseException e) {
e.printStackTrace();
}

Confused with Converting the date with SimpleDateFormat [duplicate]

This question already has answers here:
How to convert "Mon Jun 18 00:00:00 IST 2012" to 18/06/2012?
(5 answers)
Closed 5 years ago.
I have a problem with date converting. I use the following program and I expect the output: 19.05.2017
But the output is: 05.00.2017
Can anybody help?
String t = "Fri May 19 00:00:00 CEST 2017";
Date d = new SimpleDateFormat("EEE MMM DD hh:mm:ss zzzz YYYY", Locale.US).parse(t);
String s = new SimpleDateFormat("dd.mm.yyyy").format(d).toString();
System.out.println(s);
A surprising result. The oldfashioned classes SimpleDateFormat and friends are full of surprises. This is meant as a negative thing.
Uppercase DD is day of year. Lowercase hh is hour of AM or PM (1 through 12). Uppercase YYYY is weekbased year (only useful with week number). So you are asking for a date that is a Friday in May and the 19th day of the year. Obviously this is not possible.
The result of parsing is Thu Jan 05 23:00:00 CET 2017. Apparently SimpleDateFormat opts for giving you a Friday and for using the zone offset of 2 hours implied by CEST even though the date it has chosen is not at the time of year where CEST (summer time) is in use. I don’t know whether it just gives you the first Friday of the weekbased year (Friday in week 1 of the year). Friday at 0000 hours at offset GMT+2 equals Thursday at 23 at GMT+1, which is CET.
Next for the formatting, 05 is the date as expected, but lowercase mm means minutes. Since the minutes are 0, you get 00. You got the right year.
Rather than using the outdated classes that give you such surprises, I agree with Sam’s answer that you should use the newer classes in java.time:
ZonedDateTime dt = ZonedDateTime.parse(t,
DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss zzz yyyy", Locale.US));
String s = dt.format(DateTimeFormatter.ofPattern("dd.MM.uuuu"));
This code gives you 19.05.2017 as you had expected. One of the good things about the modern classes is, if you try to parse with your original format pattern string, you will get a DateTimeParseException so you will know something is wrong. I certainly prefer an exception over incorrect output.
Another good thing is these classes respect the time zone in the input and use it in the output too (unless you explicitly instruct them otherwise). They will never turn Friday 6 January into Thursday 5 January because of some funny time zone issue.
Your input date is in Central European Summer Time and your date format is a bit wrong. Try
SimpleDateFormat input = new SimpleDateFormat("EEE MMM dd hh:mm:ss zzzz yyyy");
You might want to set the timezone on the output date format in order to get the date in the correct local time.
Ideally you'd move over to use a java.time style as shown here:
https://www.mkyong.com/java/java-convert-date-and-time-between-timezone/

TimeZone Conversion with SimpleDateFormat in Java

I have a SimpleDateFormat parser that parse in this way:
sdf = new java.text.SimpleDateFormat("yyyy-MM-DD HH:mm:ss z").parse("2013-10-25 17:35:14 EDT");
log.debug(sdf);
This give me Sat Jan 26 03:05:14 IST 2013
What am i missing here?
First of all, DD stands for day in year, You should use dd instead.
Also, if you want to print a date in a specific format, you need to use two SimpleDateFormats.
SimpleDateFormat.parse returns a Date object represents the date you specified at the given format.
The Date object itself is saved as a regular Date, no format attached to it.
If you want to print it in a specific format, you need to use another SimpleDateFormat and call format method.
you should use Format
SimpleDateFormat sdf1 = new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:SS z");
String sdf = sdf1.format(sdf1.parse("2013-10-25 17:35:14 EDT"));
There are two things.
sdf is an object of Date, which represents a specific instant in time (milliseconds elapsed since another instant known as "the epoch"). There is no format which is known to this object. And how this object is printed is solely handled by its class' toString method, which prints the date in this format:
dow mon dd hh:mm:ss zzz yyyy
This is exactly what you see in your output. Note that the timezone of the machine running the program is printed in this case. If you wish to print this object in a format of your choice you should use a DateFormat. To get output for a specific timezone you have to explicitly tell it to the DateFormat object (see below).
Another thing is you should be using dd instead of DD in the pattern. D is for day in year and d is for day in month, which I believe is what you want. Now keeping in mind both the points, this is one of the solutions to your problem:
DateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss z");
sdf.setTimeZone(TimeZone.getTimeZone("EDT")); // Time Zone for output
Date d = sdf.parse("2013-10-25 17:35:14 EDT");
System.out.println(sdf.format(d)); // You need format method
which outputs:
2013-10-25 17:35:14 EDT
What are the people answering not getting here is more the question:
2013-10-25 17:35:14 EDT != Sat Jan 26 03:05:14 IST 2013
I think it is because 'EDT' is the timezone and so, when it is 17:35 in EDT is is 3:05 in the UK, ignoring Daylight saving adjustments.

How can I use Java's SimpleDateFormat to parse a timezone given as "GMT+0100 (BST)"?

I have a date that's in the form of:
Wed Aug 17 2011 09:57:09 GMT+0100 (BST)
and have a filter that takes a time in a certain format. The problem seems to be the time zone on the end, none of the format strings I'm putting in the filter seem to work for this type of date format.
For example,
Wed Aug 17 2011 09:57:09 GMT+0100 (BST)
EEE MMM dd yyyy HH:mm:ss zZ?
The time zone part of this, keeps throwing an error.
Can anyone tell me what the correct format to parse the time zones on these dates is?
"z" needs a colon between hours and minutes. "Z" is only +/-HHMM (i.e. no "GMT" prefix).
One way to parse it is: EEE MMM dd yyyy HH:mm:ss 'GMT'Z. The "BST" bit is ignored, and it's based on assumption that there's always "GMT" before offset.
I would parse out and interpret the time zone information separately, then use that to construct the Date/Calendar object in the proper time zone.
The following code seems to work well enough with your example:
String source = "Wed Aug 17 2011 09:57:09 GMT+0100 (BST)";
String tzid = "GMT" + source.substring(28, 31)
+ ":" + source.substring(31, 33);
TimeZone tz = TimeZone.getTimeZone(tzid);
// if (tz == null) ?
SimpleDateFormat f = new SimpleDateFormat("EEE MMM dd yyyy HH:mm:ss");
f.setTimeZone(tz);
Date date = f.parse(source);
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
System.out.println(date);
Prints "Wed Aug 17 08:57:09 UTC 2011".
A more sophisticated approach would be to use regex to extract individual parts ("+/-", "hh" and "mm") of the time zone offset.
Alternatively, you can attempt to discern the 3-letter time zone id (the string in between ( and )), and use the corresponding Java TimeZone if it exists.
In your particular example, though, "BST" resolves to Bangladesh Time which is GMT+0600 so you're better off with the numeric offset. "BST" here should probably be taken as British Summer Time (GMT+0100). This can be important because numeric offsets do not indicate the use of daylight savings time, which can be in effect depending on the date.
A more heuristic routine could take this into account and attempt to resolve the name first, but verify that the GMT offsets match, and fallback on the simple "GMT+hh:mm" timezones otherwise.
If you can not find a pattern matching your use case, try:
try{
new Date("Wed Aug 17 2011 09:57:09 GMT+0100 (BST)")
}catch(Exception e)
{
// Parse exception
}

Categories

Resources