Develop Reference

Java Convert UTC Date to local Date with Joda

This code is working, but I want to use Joda-Time
public static Date dateFromUTC(Date date){
return new Date(date.getTime() + Calendar.getInstance().getTimeZone().getOffset(date.getTime()));
}
I tried this, but it's not working - what's the problem with this?
public static Date dateFromUTC(Date date){
return new DateTime(date).withZone(DateTimeZone.getDefault()).toDate();
}

tl;dr
Use java.time classes instead.
Instant.now() // Capture current moment in UTC. Always in UTC, by definition.
…and…
ZonedDateTime.now() // Capture current moment as seen through the wall-clock time of the people in the region of the time zone used by default in this JVM.
Details
As others said, you misunderstood the concepts involved in these classes. A java.util.Date represents a moment in UTC, always in UTC†, never in some other time zone. So the code seen in the Question is non-sensical. You are working too hard!
java.time
The Joda-Time project is now in maintenance mode, with the team advising migration to the java.time classes. Many of the concepts are similar between Joda-Time and java.time as both projects are led by the same man, Stephen Colebourne.
When you are ready to migrate, use Instant in place of java.util.Date.
Instant instant = Instant.now() ; // Capture the current moment in UTC.
instant.toString(): 2018-01-23T12:34:56.123456789Z
Instead of java.util.Calendar, use ZonedDateTime to represent a moment seen through the wall-clock time of a particular region (a time zone).
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Pacific/Auckland" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, same point on the timeline, different wall-clock time.
As a shortcut, you can skip the Instant if you want only the zoned time.
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ; // Capture the current moment as seen by people in a certain time zone.
You can get to UTC from there by extracting an Instant object.
Instant instant = zdt.toInstant() ; // Same moment, same point on the timeline, but viewed with the wall-clock time of UTC.
† Actually, there is a time zone assigned deep within a java.util.Date but is irrelevant to our discussion here. Confusing? Yes. One of many reasons to avoid the awful mess that is the old Date/Calendar and related legacy date-time classes.
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….
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.

Try this:
new DateTime(date, DateTimeZone.UTC)
.toLocalDateTime() // value without timezone
.toDateTime() // convert to default timezone
.toDate();
Your code actually does nothing to the date, because new DateTime(date) creates a DateTime object with default timezone. And then you just convert it back to java.util.Date.

First of all, read the article linked in the comments: https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-date/
A java.util.Date doesn't have a timezone. It actually represents a point in time: the number of milliseconds since unix epoch (Jan 1st 1970, at midnight, in UTC).
When you print the Date, though, it uses the JVM default timezone to convert the Date to date/time values, but the Date itself doesn't have a timezone.
That's why converting a Date object to another timezone doesn't make sense.
If you want to know the date (day, month, year) and time (hour, minute, second, millisecond) that corresponds to the Date in a specific timezone, then you can use Joda-Time:
// java.util.Date
Date date = new Date();
// the Date converted to UTC
DateTime utc = new DateTime(date, DateTimeZone.UTC);
// the Date converted to JVM default timezone
DateTime convertedToDefaultTz= new DateTime(date, DateTimeZone.getDefault());
The conversion can also be made using another DateTime:
DateTime convertedToDefaultTz = utc.withZone(DateTimeZone.getDefault());
Joda's DateTime has a timezone attached to it, so now it makes sense to convert to another one. But the Date objects returned by it will always be the same, because all of them represent the same instant (the same point in the timeline):
Date d1 = utc.toDate();
Date d2 = convertedToDefaultTz.toDate();
System.out.println(d1.equals(d2)); // true
All because - again - a Date doesn't have a timezone.

How to get year, month, day in UTC?

I have a some Date that was gotten by Calendar.getInstance() (in local time zone as I got).
public final class Converter {
private static final TimeZone UTC_ZONE = TimeZone.getTimeZone("UTC");
private Converter() {
}
public static int toPackedUTCDate(Date date) {
Calendar c = Calendar.getInstance(UTC_ZONE);
c.setTime(date);
int year = c.get(Calendar.YEAR); // UTC year
int month = c.get(Calendar.MONTH); // UTC month
int dayOfMonth = c.get(Calendar.DAY_OF_MONTH); // UTC day of month
return TimeUtils.packDate(dayOfMonth, month, year);
}
}
Of course, it's a wrong code but how to get a correct? Cuz date was gotten by Calendar.getInstance().getTime(). Sorry, I really can't get all these time zones... If someone can explain me clearly I will be very grateful. I just need to the user could input his date (in his local time zone) and my app has stored as date in UTC in own packed format.

tl;dr
LocalDate.now( ZoneOffset.UTC )
java.time
You are using troublesome old date-time classes that are now legacy, supplanted by the java.time classes.
LocalDate
The LocalDate class represents a date-only value without time-of-day and without time zone.
Time zone
A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment, so your results may vary. Better to specify your desired/expected time zone explicitly as an argument.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" ) ;
LocalDate today = LocalDate.now( z ) ;
If you want to use the JVM’s current default time zone, ask for it and pass as an argument. If omitted, the JVM’s current default is applied implicitly. Better to be explicit.
ZoneId z = ZoneId.systemDefault() ; // Get JVM’s current default time zone.
If you want UTC, use the constant defined as ZoneOffset.UTC.
LocalDate todayUtc= LocalDate.now( ZoneOffset.UTC ) ;
Sorry, I really can't get all these time zones
These concepts have been covered many many times already on Stack Overflow, sometimes quite in-depth.
Search thoroughly before posting. Search for Instant, ZoneId, ZoneOffset, "java.time", OffsetDateTime, ZonedDateTime, DateTimeFormatter.
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.
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….

Date date = new Date(year,month,day,hour,min);
SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
Date utc= new Date(sdf.format(date));

Java/Android: how to get full date string for user language and country?

I would like to get the current date for a given user language/country. E.g.:
'Friday, 10 March 2017' (for an English user in UK ; perhaps it is 'Friday, March 10th 2017' in some other english-speaking countries)
'Vendredi 10 mars 2017' (for a French user in France)
'Freitag, 10. März 2017' for a German user
etc...
Perhaps I did not search correctly on SO and the web but I did not find convenient answers...
Thanks !

You can pass default locale with SimpleDateFormat class like this
SimpleDateFormat dateformat = new SimpleDateFormat(timeFormat, Locale.ENGLISH);

tl;dr
LocalDate.now( ZoneId.of( "America/Montreal" ) ) // Capture the current date, “today”.
.format( // Generate a string.
DateTimeFormatter.ofLocalizedDate( FormatStyle.FULL ) // Automatically localize.
.withLocale( Locale.CANADA_FRENCH ) // Specify human language for translation and cultural norms for formatting.
)
Using java.time
Add the ThreeTenABP library to your project. That library is an adaptation for Android of the ThreeTen-Backport project that back-ports to Java 6 & 7 most of the functionality of the java.time classes. The java.time classes are built into Java 8 and later. The java.time classes supplant the notoriously troublesome legacy date-time classes such as Date and Calendar.
Get the current date in the desired/expected time zone. I recommend making a habit of always specifying the time zone explicitly rather than implicitly relying on the JVM’s current default time zone.
The LocalDate class represents a date-only value without time-of-day and without time zone.
A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" );
LocalDate localDate = LocalDate.now( z );
You can get the JVM’s current default time zone with a call to ZoneId.systemDefault. Keep in mind that the current default can be changed at any moment by any code in any thread of any app within that JVM. So, if time zone is critical, confirm with the user.
Generate a string to represent that value with a DateTimeFormatter object. You can specify a formatting pattern. But you want a localized value, so let DateTimeFormatter do that work.
To localize, specify:
FormatStyle to determine how long or abbreviated should the string be.
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.
Locale locale = Locale.CANADA_FRENCH ;
DateTimeFormatter f = DateTimeFormatter.ofLocalizedDate( FormatStyle.FULL ).withLocale( locale );
Generate your string.
String output = localDate.format( f );
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.
Where to obtain the java.time classes?
Java SE 8 and 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 SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
See How to use ThreeTenABP….

If you look for a built-in way on Android without using an external library then the old-style class java.text.DateFormat is the best starting point where you can get a formatter specifying the locale without knowing the exact format pattern. See the javadoc.
DateFormat df = DateFormat.getDateInstance(DateFormat.LONG, Locale.FRANCE);
String formattedCurrentDate = df.format(new Date());

How to get Java to show the day of month from a date?

I am trying to extract the day of month of today's date. I have this
DateFormat dateFormat = new SimpleDateFormat("MM/dd/yyyy");
Date date = new Date();
JOptionPane.showMessageDialog(null, date.getDay());
but when the message dialog appears it show the number 5
and today it's the 8th. How can I set it to show what day of the month it is?

date.getDay() returns the day of the week. sunday is 0 and similarly saturday is 6.
Please see the java docs
As per the comment given below
Calendar cal = Calendar.getInstance();
int dayOfMonth = cal.get(Calendar.DAY_OF_MONTH);
String dayOfMonthStr = String.valueOf(dayOfMonth);
System.out.println(dayOfMonthStr);

Try this out.
JOptionPane.showMessageDialog(null, date.getTime());

You started to use the SimpleDateFormat class, but didn't do anything with it. Try:
System.out.println( new SimpleDateFormat("EEEE").format( new Date() ) );
System.out.println( new SimpleDateFormat("d").format( new Date() ) );

tl;dr
LocalDate.now() // Capture the current date as seen in the wall-clock time used by the people of a certain region, that region represented by the JVM’s current default time zone.
.getDayOfMonth() // Extract the day-of-month. Returns an `int`.
java.time
extract the day of month of today's date
The modern approach uses the java.time classes that supplant the troublesome old date-time classes bundled with the earliest versions of Java.
LocalDate
The LocalDate class represents a date-only value without time-of-day and without time zone.
A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment, so your results may vary. Better to specify your desired/expected time zone explicitly as an argument.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" ) ;
LocalDate today = LocalDate.now( z ) ;
If you want to use the JVM’s current default time zone, ask for it and pass as an argument. If omitted, the JVM’s current default is applied implicitly. Better to be explicit, as the default may be changed at any moment during runtime by any code in any thread of any app within the JVM.
ZoneId z = ZoneId.systemDefault() ; // Get JVM’s current default time zone.
Interrogate the LocalDate for its day-of-month.
int dayOfMonth = today.getDayOfMonth() ;
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….
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.
Joda-Time
UPDATE: The Joda-Time project is now in maintenance mode, with the team advising migration to the java.time classes. I am leaving this section intact as history.
In Joda-Time 2.3 in Java 7…
org.joda.time.DateTime theEighth = new org.joda.time.DateTime( 2013, 11, 8, 18, 0 ); // Default time zone.
System.out.println( "theEighth: " + theEighth );
System.out.println( "dayOfMonth of theEighth: " + theEighth.dayOfMonth().getAsText() );
When run…
theEighth: 2013-11-08T18:00:00.000-08:00
dayOfMonth of theEighth: 8

java gregoriancalendar off by an hour

I did:
GregorianCalendar gc = new GregorianCalendar(Locale.French);
And the hour is off by one hour. I get 14:17 instead of 15:17.
My first thought was DST, but I think gregoriancalendar takes that into account.
The time is set correctly on my pc.

The constructor you use is creating a Calendar with the default Timezone (javadoc), this might not be the timezone correct fpr the given locale. At leasst, thats how i read the javadoc. Try using a different constructor and pass your TZ in.

tl;dr
As noted in a comment, you confused using a Locale object with specifying a time zone. A locale has nothing to do with a time zone, and a locale does not affect the meaning of the date-time value. A locale affects only the formatting of a String used in presentation of the date-time value.
No locale needed when capturing the current moment. But we do need a time zone.
Instant.now().atZone( ZoneId.of( "America/Montreal" ) )
…or shorter version…
ZonedDateTime.now( ZoneId.of( "America/Montreal" ) )
java.time
You are using troublesome old legacy date-time classes, now supplanted by the java.time classes.
Work in UTC
Much of your business logic, data storage, and data exchange should be in UTC. Think of UTC as “the One True Time”.
The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds.
Instant instant = Instant.now();
Specify time zone
As you figured out, you should always specify the desired/expected time zone. For any given moment, the date and the time-of-day vary around the world by zone.
Specify a proper time zone name in the format of continent/region. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone( z );
Specify locale
Be aware that time zone and locale are orthogonal, completely separate issues.
Time zone determines the meaning of the date-time, how we view its wall-clock time.
Locale determines (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, and such.
This means we can mix-and-match any time zone with any locale. We can have a date-time in zone Europe/Paris with a locale of Locale.KOREA. Or a zone of Pacific/Auckland with Locale.CANADA_FRENCH.
So locale only impact presentation of the date-time, how we generate a String representation of the date-time.
You can specify a custom formatting pattern for generation of strings. But better to let java.time automatically localize.
Locale l = Locale.CANADA_FRENCH ;
DateTimeFormatter f = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL )
.withLocale( l );
String output = zdt.format( f );
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.
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.

I am not sure what you are trying, but GregorianCalendar(Locale) is always based on your default time zone. -- Maybe you should have a look at GregorianCalendar(TimeZone zone, Locale aLocale)