I've following code (simplified to focus on issue). That prints the timezone information using SimpleDateFormat pattern.
Do you know why z is treated differently on different machines ? And if there is a way to tell Java to treat it uniformly across all the machines ?
This class is being used in JavaMail and that is causing our email headers to include time which is not comply with RFC 2822.
import java.text.SimpleDateFormat;
import java.util.Calendar;
public class DateFormatTest {
String PATTERN = "z";
SimpleDateFormat simpleDateFormat = new SimpleDateFormat(this.PATTERN);
public static void main(final String[] args) {
new DateFormatTest().printTimezone();
}
public void printTimezone() {
System.out.println(this.simpleDateFormat.format(Calendar.getInstance().getTime()));
}
}
Output : Windows / Mac
PDT
Output : Linux (CentOS Linux release 7.5.1804 (Core)) / Ubuntu 14 / 18
GMT-07:00
tl;dr
Never use Calendar. Use java.time classes instead.
For strings in RFC 1123 / RFC 822 format:
OffsetDateTime
.now( ZoneOffset.UTC )
.format( DateTimeFormatter.RFC_1123_DATE_TIME )
Mon, 24 Sep 2018 23:45:21 GMT
To get the current offset-from-UTC in a particular time zone:
ZoneId
.systemDefault()
.getRules()
.getOffset(
Instant.now()
)
.toString()
-07:00
Avoid Calendar
You are using terrible old date-time classes that were supplanted years ago by the java.time. Never use those legacy classes; they are an awful wretched mess.
Your particular issue about Calendar behavior is moot as there is no need to ever be using that class again. Even when interoperating with old code not yet updated to java.time, you can convert easily between the legacy & modern classes via new methods added to the old classes.
ZonedDateTime zdt = myGregorianCalendar.toZonedDateTime() ;
…and…
GregorianCalendar gc = GregorianCalendar.from( zdt ) ;
java.time
Apparently you want the current offset-from-UTC for your current default time zone.
Get the current default time zone, a ZoneId.
ZoneId z = ZoneId.systemDefault() ; // Or specify ZoneId.of( "Pacific/Auckland" ) or so on.
Ask for the rules in that time zone.
ZoneRules rules = z.getRules() ;
Get the offset-from-UTC in effect in that zone at a certain moment. We will use the current moment, a Instant.
Instant now = Instant.now() ;
ZoneOffset offset = rules.getOffset( now ) ;
Generate a text representing that offset-from-UTC.
String output = "At " + now + " in zone " + z + " the offset is " + offset;
At 2018-09-24T23:38:44.192642Z in zone America/Los_Angeles the offset is -07:00
RFC 1123 / RFC 822
You mentioned an RFC but did not specify. Perhaps RFC 1123 / 822 ?
A formatter for that is built into java.time.
OffsetDateTime nowInUtc = OffsetDateTime.now( ZoneOffset.UTC ) ;
String output = nowInUtc.format( DateTimeFormatter.RFC_1123_DATE_TIME ) ;
Mon, 24 Sep 2018 23:45:21 GMT
ISO 8601
FYI, that RFC 1123 / RFC 822 format is a terrible format. It assumes English. It is difficult for machines to parse, and difficult for humans to read. But I understand that you may need it for outmoded old protocols.
Just know that modern protocols use ISO 8601 standard formats. Conveniently, these formats are used by default in the java.time classes when parsing/generating strings.
About java.time
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
Related
Hi I am trying to send the UTC offset towards my server. So I am converting the device time zone into utc offset using following code
TimeZone tz = TimeZone.getDefault();
Calendar cal = GregorianCalendar.getInstance(tz);
int offsetInMillis = tz.getOffset(cal.getTimeInMillis());
String offset = String.format("%02d:%02d", Math.abs(offsetInMillis / 3600000), Math.abs((offsetInMillis / 60000) % 60));
Log.d("UTC_Offset",offset);
Now i know as I am using the Math.abs it is not giving me the minus values but I am really dumb to know that how could I get the offset of those timezone who are in negative such as Tijuana which is GMT-07:00
Note: I may be wrong about the offset thing in UTC but this solution I found on SO. Please let me know if there is any solution or also correct me if I am wrong in idea and its that UTC could not be in negative
Use SimpleDateFormat to format it for you:
String offset = new SimpleDateFormat("Z").format(new Date());
offset = offset.substring(0, 3) + ":" + offset.substring(3);
↓↓↓↓↓ IGNORE REST OF ANSWER IF IT IS CONFUSING ↓↓↓↓↓
Results when applying to all TimeZones in the Java VM:
-12:00
-11:00
-10:00
-09:30
-09:00
-08:00
-07:00
-06:00
-05:00
-04:00
-03:00
-02:30
-02:00
-01:00
+00:00
+01:00
+02:00
+03:00
+04:00
+04:30
+05:00
+05:30
+05:45
+06:00
+06:30
+07:00
+08:00
+08:45
+09:00
+09:30
+10:00
+10:30
+11:00
+12:00
+12:45
+13:00
+14:00
Java 8 code to print the above:
Instant now = Instant.now();
SimpleDateFormat fmt = new SimpleDateFormat("Z");
ZoneId.getAvailableZoneIds().stream()
.map(z -> ZoneId.of(z).getRules().getOffset(now))
.distinct()
.sorted(Comparator.reverseOrder())
.forEach(z -> {
fmt.setTimeZone(TimeZone.getTimeZone(z));
String offset = fmt.format(Date.from(now));
offset = offset.substring(0, 3) + ":" + offset.substring(3);
System.out.println(offset);
});
tl;dr
how could I get the offset of those timezone who are in negative such as Tijuana which is GMT-07:00
ZoneId.of( "America/Tijuana" ).getRules().getOffset( Instant.now() ).getTotalSeconds()
-25200
No need to do the math yourself. We have classes for this: java.time.
For older Java before Java 8, use the ThreeTen-Backport library.
For older Android, see the ThreeTenABP project.
Avoid Date, Calendar, SimpleDateFormat, and TimeZone legacy classes.
Example:
org.threeten.bp.ZoneId
.systemDefault()
.getRules()
.getOffset(
Instant.now()
)
.toString()
To get total seconds of that offset, call ZoneOffset::getTotalSeconds.
java.time
The modern approach uses the modern java.time classes. You are using terrible date-time classes that were years ago supplanted by java.time.
Get the offset-from-UTC of the computer’s current default time zone.
ZoneId z = ZoneId.systemDefault() ;
ZoneRules rules = z.getRules() ;
ZoneOffset offset = rules.getOffset( Instant.now() ) ;
Notice that we passed a moment, represented as Instant object (a moment as seen in UTC). Politicians frequently change the offset used by the zone(s) of their jurisdiction. So the offset of your zone is likely to change over time. So you must specify a moment to ask for the offset that was in effect at that point in time.
Generate text representing that offset, using standard ISO 8601 format.
String output = offset.toString() ;
-07:00
When receiving such text, you can parse as a ZoneOffset object.
ZoneOffset offset = ZoneOffset.parse( "-07:00" ) ;
You asked:
that UTC could not be in negative
An negative offset means a place whose clocks run behind UTC. Generally, this means west (left) of the prime meridian, such as the Americas.
A positive offset means a place whose clocks run ahead of UTC. Generally, this means east (right) of the prime meridian, such as Europe, Africa, Asia.
Well, this is the commonly used meaning of positive & negative offsets, defined in the ISO 8601 standard. Some protocols and industries may use the opposite meaning. Always understand the intention of any data source you may be using.
how could I get the offset of those timezone who are in negative such as Tijuana which is GMT-07:00
ZoneId z = ZoneId.of( "America/Tijuana" ) ;
ZoneRules rules = z.getRules() ;
ZoneOffset offset = rules.getOffset( Instant.now() ) ;
String output = offset.toString() ;
System.out.println( output ) ;
See this code run live at IdeOne.com.
-07:00
About java.time
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.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
I am trying to get the timestamp value for 2018-09-04 13:43:32.922000 by doing
Timestamp.valueOf("2018-09-04 13:43:32.922000")
my expected output is 2018-09-04 13:43:32.922
but I am getting 2018-09-04 01:13:32.922
It might be due to different timezone because my team in India got the exact result but I am here in California gets the different result.
Suggest the changes that can solve this problem.
tl;dr
myPreparedStatement.setObject(
Instant
.parse(
"2018-09-04 13:43:32.922000"
.replace( " " , "T" )
.concat( "Z" )
)
.atZone(
ZoneOffset.UTC
)
)
java.time
Suggest the changes that can solve this problem.
Never use java.sql.Timestamp.
Among the many flaws of that class is that the method you call is not documented to explain its behavior while parsing. It appears your JVM’s current default time zone is being silently applied with some adjustment. But the issue is moot.
That terribly-designed class was supplanted years ago by the modern java.time classes with the adoption of JSR 310, specifically Instant and OffsetDateTime.
Change your input string to standard ISO 8601 format by replacing the SPACE in the middle with a T.
String input = "2018-09-04 13:43:32.922000".replace( " " , "T" ) ;
Was your input intended to represent a moment in UTC, an offset of zero? If so, append a Z (pronounced Zulu).
String input = "2018-09-04 13:43:32.922000".replace( " " , "T" ).concat( "Z" ) ;
The Instant class represents a moment in UTC, always in UTC by definition.
Instant instant = Instant.parse( input ) ;
Your JDBC driver may optionally accept a Instant object.
myPreparedStatement.setObject( instant ) ;
If your JDBC driver does not support Instant, use OffsetDateTime. Support is required in JDBC 4.2 and later.
OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ;
myPreparedStatement.setObject( odt ) ;
Notice how your JVM’s current default time zone at runtime is irrelevant, with no impact on the code above.
About java.time
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
I do not think the issue is due to different time zones. Its just that the output that you are getting is in 24 hour format and that needs to be converted to 12 hour format. Please refer How to convert 24 hr format time in to 12 hr Format? to convert the time to 12 hour format.
I have an android app that receives a string in this format:"MM-dd-yyyy HH:mm:ss" from my server. I want to convert this string to a Date object with UTC as timezone since the time in the string is UTC. I've already checked several similar questions but didn't find my answer
Here is what I'm using currently:
SimpleDateFormat format = new SimpleDateFormat("MM-dd-yyyy HH:mm:ss");
Date date = new Date();
try {
date = format.parse(itemContent [3]);
entity.setValidTill(date);
}catch (Exception e){
}
But what it does when I print that date with Log is show it as:
Sun Aug 27 15:00:00 GMT+04:00 2017
I want it to be:
Sun Aug 27 15:00:00 GMT 00:00 2017
So here is the main question how to get DateTime for UTC using a string with format as above?
Edit:
Just put it in a better context. I'm trying to get users to see the difference between current datetime & the that datetime saved in server. So my solution was to get gmt time for users & compare with the server time(which is gmt) so everyone see same difference regardless of their timezone. With C# you can get DateTime.UtcNow while with java I couldn't find an alternative
Briefly, as your Question is really a duplicate of many others…
You are using troublesome old date-time classes that are now legacy, supplanted by the java.time classes.
Parse your input string as a LocalDateTime as it lacks any indicator of offset-from-UTC or time zone.
Define a formatter to parse your input string.
String input = "08-27-2017 15:00:00" ;
DateTimeFormatter f = DateTimeFormatter.ofPattern( "MM-dd-uuuu HH:mm:ss" ) ;
LocalDateTime ldt = LocalDateTime.parse( input , f ) ;
ldt.toString(): 2017-08-27T15:00
A LocalDateTime is not a moment on the timeline, only a rough idea about a range of possible moments. Has no meaning without the context of an offset (or time zone).
If you are certain that input was intended for UTC, assign the constant ZoneOffset.UTC for a OffsetDateTime.
OffsetDateTime odt = ldt.atOffset( ZoneOffset.UTC ) ;
odt.toString(): 2017-08-27T15:00Z
To calculate a delta between that moment and the current moment, use the Period class for coarser granularity in your span of time, or Duration for finer granularity. Both classes generate strings in standard ISO 8601 format of PnYnMnDTnHnMnS.
OffsetDateTime now = OffsetDateTime.now( ZoneOffset.UTC ) ;
Duration d = Duration.between( odt , now ) ;
now.toString(): 2017-08-27T21:16:56.396Z
d.toString(): PT6H16M56.396S
See this code run live at IdeOne.com.
In the standard strings seen above, the Z is short for Zulu and means UTC.
About java.time
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?
Java SE 8, Java SE 9, Java SE 10, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
just add this code under the first line of your code:
format.setTimeZone(TimeZone.getTimeZone("UTC"));
I have a date time value 2016-12-21T07:48:36 with an offset of UTC+14. How to convert the datetime into equivalent standard GMT time.
I tried with sampleDateFormat.parse() method.But, I am not able to get the TimeZone object for UTC offset like.
sampleDateFormat.setTimeZone(TimeZone.getTimeZone("UTC+14:00"))
Please help me to convert the UTC datetime into standard GMT time in Java 7.
I will assume you have the original date as a string. Do the following:
Create a SimpleDateFormat and set the timezone to "GMT+14"
Parse the string value. You get a Date object
Set the timezone of the SimpleDateFormat to "UTC" (or use a different SimpleDateFormat instance)
Format the date (if you want the result as a string as well)
Example:
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.TimeZone;
public class ConvertToUTC {
public static void main(String[] args) throws Exception {
String dateval = "2016-12-21T07:48:36";
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
df.setTimeZone(TimeZone.getTimeZone("GMT+14"));
Date date = df.parse(dateval);
System.out.println(df.format(date)); // GMT+14
df.setTimeZone(TimeZone.getTimeZone("UTC"));
System.out.println(df.format(date)); // UTC
}
}
use "GMT+14:00" instead of "UTC+14:00"
SimpleDateFormat f = new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ss");
f.setTimeZone(TimeZone.getTimeZone("GMT+14:00"));
final Date d = f.parse("2016-12-21T07:48:36");
f.setTimeZone(TimeZone.getTimeZone("UTC"));
System.out.println(f.format(d)); // -> 2016-12-20T05:48:36
tl;dr
LocalDateTime.parse( "2016-12-21T07:48:36" ) // Parse as a `LocalDateTime` given the lack of an offset or zone. *Not* an actual moment, only a rough approximation of potential moments along a range of about 26-27 hours.
.atOffset( ZoneOffset.ofHours( 14 ) ) // Assign an offset-from-UTC as context, giving meaning to determine an actual point on the timeline.
.toInstant() // Renders `Instant` object in UTC.
java.time
The modern way is with the java.time classes built into Java 8 and later. Much of the functionality is back-ported to Java 6 & 7 in the ThreeTen-Backport project.
ZoneOffset offset = ZoneOffset.ofHours( 14 ); // fourteen hours ahead of UTC.
Parse the string as a LocalDateTime as it lacks any info about offset or zone. Your input is in standard ISO 8601 format, so no need to specify a formatting pattern.
LocalDateTime ldt = LocalDateTime.parse( "2016-12-21T07:48:36" );
Apply the offset to the local date-time to get an OffsetDateTime an object.
OffsetDateTime odt = ldt.atOffset( offset );
From that, extract an Instant which is always in UTC.
Instant instant = odt.toInstant();
instant.toString(): 2016-12-20T17:48:36Z
In UTC, the value is a different date, the 20th instead of 21st.
See live code at IdeOne.com.
About java.time
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.
Using a JDBC driver compliant with JDBC 4.2 or later, you may exchange java.time objects directly with your database. No need for strings nor java.sql.* classes.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
This question already has answers here:
Java / convert ISO-8601 (2010-12-16T13:33:50.513852Z) to Date object
(4 answers)
Closed 6 years ago.
I am trying to parse a String using SimpleDateFormat.
This is my current code:
public String getCreatedDateTime() {
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-ddEHH:mm:ss.zzzz");
try {
Date date = simpleDateFormat.parse("2015-06-27T13:16:37.363Z");
return date.toString();
} catch (ParseException e) {
return "Error parsing date";
}
}
As you can see, I just put a constant in the parse() method for testing purposes.
So, this is what I am trying to parse:
2015-06-27T13:16:37.363Z
This is the SimpleDateFormat pattern that I am using:
yyyy-MM-ddEHH:mm:ss.zzzz
I keep getting the ParseException.
I know that it is proably because of the .zzzz at the end but I have no idea what .363Z might stand for so I just used some random letters. Bad idea.
I'll appreciate your help a lot. Thank you!
Try with this pattern (note the X at the end and the 'T' in the middle):
"yyyy-MM-dd'T'HH:mm:ss.SSSX"
From Java's SimpleDateFormat's documentation:
ISO 8601 Time zone:
...
For parsing, "Z" is parsed as the UTC time zone designator.
And, from the part where it describes the different characters:
X - Time zone - ISO 8601 time zone
EDIT
If using Android, then "X" is not supported.
You can use this pattern (note Z is a literal now):
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"
But then you'll get the date on your current timezone and would need to convert it to UTC if needed.
tl;dr
Skip the formatting pattern. Standard ISO 8601 format is used by default.
Instant.parse( "2015-06-27T13:16:37.363Z" )
ISO 8601
Your string format is formally defined by the ISO 8601 standard.
Basically your Question is a duplicate of this one, Converting ISO 8601-compliant String to java.util.Date.
Alternatives
The Answer by eugenioy is correct.
But you should know that the old java.util.Date/.Calendar/java.text.SimpleDateFormat classes bundled with Java are notoriously troublesome and should be avoided.
Outmoded Classes
Those old classes are now outmoded, first by the third-party Joda-Time library, and now by the new java.time package (Tutorial) built into Java 8 and later (inspired by Joda-Time, defined by JSR 310, extended by the ThreeTen-Extra project).
Both java.time and Joda-Time use the ISO 8601 standard as their defaults when parsing/generating string representations of date-time values. So the code is simple, no need for custom formatter objects. No need for all that format twiddling that caused your Exception.
Time Zone
Both java.time and Joda-Time have a zoned date-time class that understands its assigned time zone (unlike java.util.Date). If you do not assign one, the JVM’s current default time zone is assigned.
Beware that the JVM’s current default time zone can change at any time. It can change at deployment, defaulting to whatever the host OS setting is. And it can change at any moment during runtime when any code in any thread of any app within the JVM calls TimeZone.setDefault. So better to explicitly assign a desired/expected time zone.
java.time
The Z on the end of your string is short for Zulu and means UTC. The Instant class can directly parse that format, to represent a moment on the timeline in UTC with a resolution in nanoseconds.
String input = "2015-06-27T13:16:37.363Z";
Instant instant = Instant.parse( input );
Change the time zone from UTC to some desired/expected time zone.
ZoneID zone = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdtMontréal = instant.atZone( zone ) ;
If you really need a java.util.Date for interoperability, convert.
java.util.Date utilDate = Date.from( zdtMontréal.toInstant() ) ;
Joda-Time
The Joda-Time project is now in maintenance mode, with the team advising migration to the java.time classes:
Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310) - a core part of the JDK which replaces this project.
Example code using Joda-Time 2.8.1.
String input = "2015-06-27T13:16:37.363Z" ;
DateTimeZone zone = DateTimeZone.UTC ; // Or: DateTimeZone.forID( "America/Montreal" ) ;
DateTime dateTime = new DateTime( input, zone ) ;
If you really need a java.util.Date for interoperability, convert.
java.util.Date date = dateTime.toDate();
About java.time
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.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.