1

I want to convert the seconds from DEC 31ST 1969 7 PM to date/time in the following java code.

package sampProp;

import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.StringTokenizer;
import java.util.TimeZone;


public class sample 
{    
    public static void main(String args[])  
    {

     //Here 1373605580 is the number os secs from DEC 31ST 1969 7 PM
     long millisecs = (long)(1373605580) *1000;

     DateFormat df = new SimpleDateFormat("MM/dd/yyyy_HH:mm:ss a");

     df.setTimeZone(TimeZone.getTimeZone("EST"));

     Date d1 = new Date(millisecs);

     String formattedDate = df.format(d1); 

     System.out.println("Formatted date is "+formattedDate);

    } 
}

I'm running the code on AIX server.

My development server gives the value 07/12/2013_00:06:20 which is the correct one but my production server gives 07/12/2013_01:06:20 which is not correct.

How is this possible. And how can I correct this.

My Development server's java-version output is: 

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pap64dev-20071008 (SR6))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc64-64 j9vmap6423-20071007 (JIT enabled)
J9VM - 20071004_14218_BHdSMr
JIT  - 20070820_1846ifx1_r8
GC   - 200708_10)
JCL  - 20071008

And my production server's java-version output is:

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pap64dev-20080315 (SR7))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc64-64 j9vmap6423-20080315 (JIT enabled)
J9VM - 20080314_17962_BHdSMr
JIT  - 20080130_0718ifx2_r8
GC   - 200802_08)
JCL  - 20080314
Dark Matter
  • 2,231
  • 3
  • 17
  • 31
  • What JDK or JRE build do you have on each of the two machines? Also, you know that using the three-letter timezone codes is deprecated, right? – Dawood ibn Kareem Nov 04 '13 at 17:43
  • What is your use case for this? Can you use Joda-Time instead? http://www.joda.org/joda-time/ – MetroidFan2002 Nov 04 '13 at 17:44
  • 1
    You can't always just recommend Joda-Time as a fix-all when nothing seems to be wrong... I can't see anything wrong with this code so it would be interesting to figure out the actual problem. – Sebastiaan van den Broek Nov 04 '13 at 17:46
  • I've added my java version details. I cannot convert to JODA time at this stage because this is used everywhere and I have to change in more than 100 places.Can you please suggest an alternative. – Dark Matter Nov 04 '13 at 17:48
  • That's some pretty ancient Java version btw. I have no idea what kind of bugs there are in the date/time libs there. Can you easily upgrade? If not you may want to search for release notes concerning date/time fixes. – Sebastiaan van den Broek Nov 04 '13 at 17:52
  • What happens if you use the full name of the timezone, instead of referring to it as "EST"? – Dawood ibn Kareem Nov 04 '13 at 17:54
  • 1
    My best guess is that your two Java versions have different mappings from "EST" (which is ambiguous, when it comes to Daylight Savings rules) to real timezones (such as America/New_York, America/Kentucky/Louisville and so on), each of which includes a set of Daylight Savings rules, as well as an offset from GMT. It's always safest to use the full name of the timezone. – Dawood ibn Kareem Nov 04 '13 at 18:01
  • 1
    not sure of your local time-zone, but in the US we just had the roll-back from Daylight-Savings Time, to Standard Time. Could this have affected your testing? Good luck. – shellter Nov 04 '13 at 18:07
  • I cannot upgrade the java version on a moment's notice. So for the full time zone name do I need to give "Eastern Standard Time". – Dark Matter Nov 04 '13 at 18:13
  • Can you add `z Z` to your format string so we can see what Timezone it's reporting in. Also, can you type `locale` and `date` on your shell and show the result? – Alastair McCormack Nov 04 '13 at 18:20
  • @David Wallace : So how would I verify that and how can I solve that. And what do you mean by I have to use the full name of the timezone. – Dark Matter Nov 04 '13 at 18:23
  • OK, first read and understand Zenbeni's answer, including the page on the IBM site that he/she linked to. The best way to solve your issue is not to use a three-letter timezone name like "EST". These are deprecated. Please use the full name of the timezone that you're interested in, for example "America/New_York". There is a list of these at http://en.wikipedia.org/wiki/List_of_tz_database_time_zones - obviously, I don't know which one is yours. – Dawood ibn Kareem Nov 04 '13 at 18:26
  • I printed the time zone along with the time , on my dev it prints `07/12/2013_00:06:20 AM EST` and on my prod it prints `07/12/2013_01:06:20 AM EDT` for the same code. What is happening here. – Dark Matter Nov 04 '13 at 18:37
  • I used the GMT-5 time zone and the issue was resolved – Dark Matter Nov 04 '13 at 18:52

2 Answers2

1

Is it because your timezone is not correctly set on your server?

Check this question and answer: java incorrect timezone

Check the timezone of your JVM in your dev server and on your production server.

EDIT

As many said: it SHOULD not come from that, still it is weird and your configuration seem pretty similar between your two servers (still: JVM are not the same). There should be a difference, so check JVM args and system variables and looking at timezones seem a first go for me.

RE-EDIT:

As David mentioned: it is a bug about saving time:

Here is the link: http://www.coderanch.com/t/458357/java/java/AIX-Timezone-Java-showing-hour

And the link from IBM: http://www-01.ibm.com/support/docview.wss?uid=swg21250503

I quote:

In 2006, the meaning of the EST time zone identifier changed in the Olson database. Historically, EST referred to the American Eastern Standard Time and made adjustments for daylight saving time. Following the change, EST refers to Eastern Standard Time with no adjustment for daylight saving time. A new identifier EST5EDT was also introduced that had the same meaning as the original EST identifier. EST5EDT therefore refers to the American Eastern Standard Time and makes adjustments for daylight saving time.

The best way to avoid these problems is to use long time zone identifiers like America/New_York.

If you cannot change an application to use the long time zone identifiers, you can set the system property ibm.dst.compatibility or sun.timezone.ids.oldmapping to alter the interpretation of EST or MST.

Community
  • 1
  • 1
zenbeni
  • 7,019
  • 3
  • 29
  • 60
  • Theoretically this shouldn't matter a thing, since he's doing no formatting with the timezone of the server itself. – Sebastiaan van den Broek Nov 04 '13 at 17:45
  • There is new Date(millis) and Date should have a timezone depending on the JVM timezone. – zenbeni Nov 04 '13 at 17:47
  • This is very unlikely to be the right answer. The code in the question shouldn't even LOOK at the server's timezone. – Dawood ibn Kareem Nov 04 '13 at 17:47
  • 1
    That's just plain wrong zenbeni. Dates do NOT have timezone information at all. – Sebastiaan van den Broek Nov 04 '13 at 17:48
  • My bad, you're right. It is just the JVM that parses the Date. Still can't be a bad idea to check differences through server configurations. – zenbeni Nov 04 '13 at 17:58
  • Now that the further investigation has been done, and the quote from IBM has been added, I'm certain that this is the right answer. A good piece of research. +1. – Dawood ibn Kareem Nov 04 '13 at 18:22
  • If I use the "America/New_York" timezone it will account for daylight savings time and I don't want that to happen. So what would be the best way to solve this. – Dark Matter Nov 04 '13 at 18:26
  • Make sure you have `sun.timezone.ids.oldmapping=false` on your production server, so that you get EST without DST. Refer to http://stackoverflow.com/questions/5189914/setting-system-property for setting system properties. – Dawood ibn Kareem Nov 04 '13 at 18:32
  • @David could not have found without your hints. Learnt stuff today :) – zenbeni Nov 04 '13 at 18:48
0

tl;dr

  • Use java.time classes
  • Specify your desired/expected time zone

Ex:

Duration.between( 
    Instant.EPOCH , 
    Instant.now() 
)

Avoid legacy date-time classes

The terrible old date-time classes bundled with the earliest versions of Java were supplanted years ago by the java.time classes.

For a moment seen through the wall-clock time used by the people of a particular region (a time zone), use ZonedDateTime. For a moment in UTC, use Instant.

Use proper time zone names

Specify a proper time zone name in the format of Continent/Region, such as Europe/Paris, Africa/Casablanca, or Pacific/Auckland. Never use the 2-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" ) ;

ZoneId

number os secs from DEC 31ST 1969 7 PM EST

Firstly, EST is not a time zone, as discussed above. I assume you mean a time zone from the east coast of North America such as America/New_York. 

ZoneId z = ZoneId.of( "America/New_York" ) ;

ZonedDateTime

For a moment in a time zone, we need ZonedDateTime.

ZonedDateTime zdt = ZonedDateTime.of( 1969 , 12 , 31 , 17 , 0 , 0 , 0 , z ) ;

zdt.toString(): 1969-12-31T17:00-05:00[America/New_York]

Duration

To represent a span of time as a count of seconds, use the Duration class.

ZonedDateTime now = ZonedDateTime.now( z ) ;
Duration d = Duration.between( zdt , now ) ;

now.toString(): 2018-12-26T19:32:08.136846-05:00[America/New_York]

d.toString(): PT429410H32M8.136846S

Ask for the entire span-of-time in terms of whole seconds.

long wholeSeconds = d.getSeconds();

wholeSeconds: 1545877928

Instant

I noticed your origin time is of a few hours before 1970 in EST happens to be in UTC the first moment of 1970. That moment, 1970-01-01T00:00:00Z, is a common epoch reference, commonly known as Unix Time. That moment is also the epoch reference used by the java.time classes.

I suspect you fell into the trap of parochial thinking, using the perspective of your own personal time zone. This is not wise when programmer. When the programmer is on the job, you should be thinking in UTC, storing in UTC, logging in UTC, and exchanging data in UTC, nearly all the time. Only apply a time zone when required by business logic or when expected by the user in the user-interface.

To track a moment in UTC, use Instant. For the epoch reference of 1970-01-01T00:00:00Z, use the constant Instant.EPOCH.

Duration d = Duration.between( Instant.EPOCH , Instant.now() ) ;

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?

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.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • 1
    Great answer. Now could you please rewrite the original program with the 'modern tools' to show their superiority and also show that they work on Aix5.x and IbmJava1.5 – Lorinczy Zsigmond Dec 27 '18 at 06:49