CET to GMT function in Java

Question

Im trying to convert a CET time format to GMT. The reason is because I am getting the date from XML and inserting it into antother system that uses GMT date format. So whatever date I am inserting is getting one day in the past.

Here I get from XML and insert it to Java object:

Date dob = DateUtils.fromXMLGregorianCalendar(customer.getDateOfBirth());
toYYYYMMDD(dob);
CETtoGMT(dob);
personalAccount.setBirthDate(dob);

My functions:

public static String toYYYYMMDD(Date day) {
    SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
    String date = formatter.format(day);
    return date;
}
public String CETtoGMT(Date cetDate) {
    SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
    formatter.setTimeZone(TimeZone.getTimeZone("GMT"));
    String date = formatter.format(cetDate);
    return date;
}

Im not sure what I am doing wrong but my tests say that I am using time zone of Oslo for the object personalAccount Birth date:

Sun Feb 24 00:00:00 CET 1990
cdate = {Gregorian$Date@3163} "1990-02-24T00:00:00.000+0100"
 cachedYear = 1990
 cachedFixedDateJan1 = 724642
 cachedFixedDateNextJan1 = 725007
 era = null
 year = 1990
 month = 2
 dayOfMonth = 24
 dayOfWeek = 1
 leapYear = false
 hours = 0
 minutes = 0
 seconds = 0
 millis = 0
 fraction = 0
 normalized = true
 zoneinfo = {ZoneInfo@3165} "sun.util.calendar.ZoneInfo[id="Europe/Oslo",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=141,lastRule=java.util.SimpleTimeZone[id=Europe/Oslo,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]"
 zoneOffset = 3600000
 daylightSaving = 0
 forceStandardTime = false
 locale = null

Answer 1

tl;dr

customer.getDateOfBirth()                     // Assuming this call returns a `XMLGregorianCalendar`. 
    .toGregorianCalendar​()                    // Convert `XMLGregorianCalendar` to the legacy class `GregorianCalendar`, en route to a `ZonedDateTime` in next line.
    .toZonedDateTime()                        // Convert from `GregorianCalendar` to `ZonedDateTime`, from legacy class to modern class.
    .toOffsetDateTime()                       // Convert to `OffsetDateTime` to better document that we are moving to an offset-from-UTC rather than a full time zone.
    .withOffsetSameInstant( ZoneOffset.UTC )  // Adjust into UTC. Same moment in time, same point on the timeline, but viewed through a different wall-clock time.
    .toLocalDate()                            // Extract a date-only value, without time zone and without time-of-day.
    .toString()                               // Generate a string in standard ISO 8601 format YYYY-MM-DD.
;

Date is UTC, but its toString is not

The java.util.Date class represents a moment in UTC. Unfortunately, its toString method confusingly applies the JVM’s current default time zone while generating a string. This has been explained many many many times already on Stack Overflow.

Avoid legacy classes

Date is one of the troublesome old date-time classes that are now legacy, supplanted entirely by the modern java.time classes.

java.time

You can convert from the legacy classes by calling new methods added to the old classes. If your code is returning a XMLGregorianCalendar object, convert first to a GregorianCalendar.

GregorianCalendar gc = customer.getDateOfBirth().toGregorianCalendar​() ;  // Returning a XMLGregorianCalendar, then converting to a GregorianCalendar.

Convert into java.time. The counterpart to GregorianCalendar​ is ZonedDateTime.

ZonedDateTime zdt = gc.toZonedDateTime() ;

Your goal is UTC. So convert to OffsetDateTime, then adjust into UTC.

OffsetDateTime odt = zdt.toOffsetDateTime().withOffsetSameInstant( ZoneOffset.UTC ) ;

Apparently you want the date-only of that UTC adjustment, so extract a LocalDate to represent a date without a time-of-day and without a time zone.

LocalDate ld = odt.toLocalDate() ;

To be clear to all readers… Determining a date requires a time zone. For any given moment, the date varies around the globe. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec. We had to go through all these steps to preserve the vital time zone (or offset-from-UTC) information so as to get the correct date.

Strings

Your desired output seems to be a String in standard ISO 8601 format. The java.time classes use standard formats by default when parsing/generating strings. So no need to specify a formatting pattern.

String output = ld.toString() ;

Time zones

By the way, never use CET or other such 3-4 letter pseudo-zones. These are not true time zones, not standardized, and not even unique(!).

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( "Europe/Paris" );  // Or "Europe/Berlin" or "Africa/Tunis" etc.
ZonedDateTime zdt = zdt.withZoneSameInstant( z ) ;

---

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
  • The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
  • 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.