Search code examples
javatimestampjava.util.date

Why does util.Date forwards the date instead of subtracting it?

I am trying to convert IST to UTC epoch in Java But instead of subtracting 5.30 hours from IST, it adds 5.30 in IST

public static long convertDateToEpochFormat(String date) {
    Date convertedDate = null;
    try {
        LOGGER.info(date);
        DateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
        LOGGER.info(date);
        convertedDate = formatter.parse(date);
        LOGGER.info(convertedDate);
    } catch (ParseException e) {
        e.printStackTrace();
    }
    return convertedDate.getTime() / 1000L;
}

The log statements I obtained is : 

2017-01-01 00:00:00
2017-01-01 00:00:00
Sun Jan 01 05:30:00 IST 2017

It should ideally be Dec 31 18:30:00 because of UTC conversion.

Can anyone tell me whats wrong ?

Solution

  • tl;dr

    Why does util.Date forwards the date instead of subtracting it?

    Because India time is ahead of UTC, not behind.

    Instant.parse(
    "2017-01-01 00:00:00".replace( " " , "T" ) + "Z" 
).atZone(
    ZoneId.of( "Asia/Kolkata" )
).toString()

    2017-01-01T05:30+05:30[Asia/Kolkata]

    Using java.time

    You are using troublesome old date-time classes that are now legacy, supplanted by the java.time classes.

    ISO 8601

    Your input string is almost in standard ISO 8601 format. To comply fully, replace that SPACE in the middle with a T. The java.time classes use standard formats when parsing/generating strings. So no need to specify a formatting pattern.

    String input = "2017-01-01 00:00:00".replace( " " , "T" ) ;

    If that input is meant to represent a moment in UTC, append a Z, short for Zulu, means UTC. 

    String input = "2017-01-01 00:00:00".replace( " " , "T" ) + "Z" ;  // Assuming this input was intended to be in UTC.

    2017-01-01T00:00:00Z

    When possible, just use the ISO 8601 formats in the first place when serializing date-time values to strings.

    Instant

    Parse that input string as an Instant, a moment on the timeline in UTC with a resolution of nanoseconds.

    Instant instant = Instant.parse( input ) ;

    instant.toString(): 2017-01-01T00:00:00Z

    ZonedDateTime

    You seem to want this value adjusted into India time. Apply a ZoneId to get a ZonedDateTime.

    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( "Asia/Kolkata" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;

    zdt.toString(): 2017-01-01T05:30+05:30[Asia/Kolkata]

    See this code run live at IdeOne.com.

    India time is ahead of UTC

    Your Question expects the India time to go backwards, behind the UTC value. This makes no sense. India time is ahead of UTC, not behind UTC. The Americas have time zones behind UTC as they lay westward. East of the Prime Meridian in Greenwich are offsets ahead of UTC. In modern times, ISO 8601 and most other protocols mark such offsets with a plus sign: +05:30. Note that some old protocols did the opposite (used a negative sign).

    Midnight UTC = 5:30 AM India

    So midnight in UTC, 00:00:00 at the Prime Meridian, is simultaneously five-thirty in the morning in India.

    So all three of these represent the same simultaneous moment, the same point in the timeline:

    • 2017-01-01T00:00:00Z
    • 2017-01-01T05:30+05:30[Asia/Kolkata]
    • 2016-12-31T16:00-08:00[America/Los_Angeles]

    Avoid count-from-epoch

    Do not handle time as an integer count from epoch as you are doing by returning a long from your method as seen in the Question. In your Java code pass around date-time values using date-time objects, java.time objects specifically. When passing date-time values outside your Java code, serialize to strings using the practical ISO 8601 formats.

    Relying on an integer count-from-epoch values is confusing, difficult to debug, impossible to read by humans, and will lead to frustration and errors (even worse: unobserved errors).

    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?

    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.