Home/ Questions/Q 8990447
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T22:30:08+00:00

I’ve a doubt about the java Date and SimpleDateFormat . I have an application,

  • 0

I’ve a doubt about the java Date and SimpleDateFormat.

I have an application, which maintains its file creation time in GMT in the format yearMonthDayHourMinute. Currently I am in a different TimeZone (say IST). So I want to do all my processing in the GMT format.

Following snippet shows, how I retrieved convert the date which is stored in my object in to TimeInMillis.

>        1. SimpleDateFormat valueSDF = new SimpleDateFormat("yyyyMMddHHmm");
>        2. valueSDF.setTimeZone(TimeZone.getTimeZone("GMT"));
>        3. Date date = valueSDF.parse("201212060915");
>        4. System.out.println("date.getTime():  "+ date.getTime());   // returns 1354785300000
>        5. String fileCreationTime= Long.toString((date.getTime()/1000));
>        6. System.out.println("time :: "+ fileCreationTime);   // returns 1354785300

The retrieved value in time in millis (step #4) is having an extra three trailing zeros. What my application needs is the result divided by 1000.(step #5)

I am curious to know, why date.getTime() appends more number of zeros to the results.
Stack experts, please share your suggestions !

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I am curious to know, why date.getTime() appends more number of zeros to the results.

    It doesn’t. It gives the number of milliseconds since the Unix epoch. If you need the number of seconds since the Unix epoch of January 1st 1970, midnight UTC, you need to divide by 1000. If you want milliseconds (as you claim) then don’t divide by 1000. That’s all there is to it – it’s behaving exactly as intended.

    It’s not clear why you thinking it’s “adding” three zeroes, but I can assure you that it’s not. Note that 1354785300 milliseconds would only be 376 hours since the Unix epoch…

    The date you’ve given (December 6th 2012, 9:15am in UTC) is 1354785300000 milliseconds since the Unix epoch. Why do you expect a result of 1354785300?

    What my application needs is the result divided by 1000

    That’s incompatible with your claim that it needs milliseconds.

    • 0