Reputation: 17
I am converting UTC time into local time and I facing the error:
org.threeten.bp.format.DateTimeParseException: Text 'Wed Oct 17 06:12:19 GMT+05:30 2018' could not be parsed at index 20
Please say any other options or fix this solution..
This is my code, please check it:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss z yyyy", Locale.ENGLISH);
String formattedDate = LocalDateTime.parse(UTC_time, formatter)
.atOffset(ZoneOffset.UTC)
.atZoneSameInstant(ZoneId.systemDefault())
.format(formatter);
Upvotes: 1
Views: 4837
Reputation: 86324
First, it seems that your string may come from calling toString
on an old-fashioned java.util.Date
object. If this is the case, you may see if you can get hold on the Date
object itself and convert it using DateTimeUtils
(from ThreeTenABP) and save all trouble of parsing.
Second, your code works with the built in java.time on my desktop computer, and I don’t know why it doesn’t work with the backport. A possible fix for the backport is:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss OOOO yyyy", Locale.ENGLISH);
String inputString = "Wed Oct 17 06:12:19 GMT+05:30 2018";
String formattedDate = OffsetDateTime.parse(inputString, formatter)
.atZoneSameInstant(ZoneId.systemDefault())
.format(formatter);
System.out.println(formattedDate);
On my computer in Europe/Copenhagen time zone this outputs:
Wed Oct 17 02:42:19 GMT+02:00 2018
EDIT: While it doesn’t seem to be documented that the backport supports the O
format pattern letter, the above works on ThreeTen Backport 1.3.6 on my Mac. The documented alternative is the following variant of the format pattern:
DateTimeFormatter formatter
= DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss 'GMT'xxx yyyy", Locale.ROOT);
If you prefer a time zone abbreviation like CEST
over the GMT offset, you may use your original formatter for formatting back into a string. The trick is that OOOO
in the format pattern parses GMT+05:30
and this style of GMT or UTC offset in general.
I have fixed another bug in your code: When you were parsing into a LocalDateTime
, you lost the time zone or offset information from the string, which caused your time to be wrong. Specifically, when there was GMT+05:30
in the string and you did .atOffset(ZoneOffset.UTC)
, the time was off by 5 hours 30 minutes. Use an OffsetDateTime
for parsing instead (if z
for zone name had worked, you would have needed a ZonedDateTime
).
Link: Documentation of org.threeten.bp:format.DateTimeFormatter
including the format pattern letters
Upvotes: 1