I am trying to parse a date, but I am oddly getting an exception.
This is the code:
import java.util.Date;
String strDate = \"Wed, 09 Feb 2011 12:3
It's probably because of the default locale on your computer which is not english.
You should use:
new SimpleDateFormat("EEE, dd MMM yyyy HH:mm:ss", Locale.ENGLISH);
instead.
java.util.Date.from (
LocalDateTime.parse(
"Wed, 09 Feb 2011 12:34:27" ,
DateTimeFormatter.ofPattern( "EEE, dd MMM uuuu HH:mm:ss" , Locale.US )
).atZone( ZoneId.of( "America/Montreal" ) )
.toInstant()
)
The Question and other Answer both use outdated troublesome old date-time classes that are now legacy, supplanted by the java.time classes.
The input string lacks any indication of a time zone or offset-from-UTC. So we parse as an OffsetDateTime.
Specify a Locale to determine (a) the human language for translation of name of day, name of month, and such, and (b) the cultural norms deciding issues of abbreviation, capitalization, punctuation, separators, and such.
String input = "Wed, 09 Feb 2011 12:34:27" ;
Locale l = Locale.US ;
DateTimeFormatter f = DateTimeFormatter.ofPattern( "EEE, dd MMM uuuu HH:mm:ss" , l ) ;
LocalDateTime ldt = LocalDateTime.parse( input , f ) ;
ldt.toString(): 2011-02-09T12:34:27
Both the Question and other Answer ignore the crucial issue of time zone.
The input string lacks a time zone or offset. We parsed as an LocalDateTime
which is not a moment on the timeline, only a vague idea about possible moments. Like saying "Christmas begins at midnight on December 25, 2017", that has no meaning until you place it in the context of a particular time zone. Christmas comes much earlier in Auckland New Zealand than it does in Paris France, and much later still in Montréal Québec.
If you know the intended time zone, assign a ZoneId
to produce a ZonedDateTime
.
ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = ldt.atZone( z ); // Assigning a time zone to determine an actual moment on the timeline.
Best to avoid the troublesome old legacy date-time classes. But if you must interact with old code not yet updated to the java.time types, you can convert between the legacy classes and java.time. Look to new methods add to the old classes.
A java.util.Date
is a moment on the timeline in UTC. So we need to extract an Instant
from our ZonedDateTime
. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Instant instant = zdt.toInstant() ;
java.util.Date d = java.util.Date.from( instant ) ; // Convert from java.time to legacy class.
Going the other direction.
Instant instant = d.toInstant() ; // Convert from legacy class to java.time class.
ZonedDateTime zdt = instant.atZone( z ) ; // Adjust from UTC into a particular time zone.
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.*
classes.
Where to obtain the java.time classes?
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.