When I try to print the current date and time using Calender instance, the result I get is 1 hour ahead from the actual time.
I am working in remote machine which r
Never use the 3-letter time zone codes. They are neither standardized nor unique. Your "EST" can mean at least these:
Use time zone names.
You have discovered one of the many reasons to avoid using java.util.Date & java.util.Calendar classes bundled with Java: A Date
instance has no time zone information yet its toString
method confusingly renders a string based on your Java environment's default time zone.
Use a competent date-time library. In Java that means either Joda-Time, or in Java 8, the new java.time.* classes (inspired by Joda-Time).
Example code…
// Default time zone
DateTime dateTime_MyDefaultTimeZone = new DateTime();
// Specific time zone. If by "EST" you meant east coast of United States, use a name such as New York.
DateTimeZone timeZone = DateTimeZone.forID( "America/New_York" );
DateTime dateTime_EastCoastUS = new DateTime( timeZone );
Dump to console…
System.out.println( "dateTime_MyDefaultTimeZone: " + dateTime_MyDefaultTimeZone );
System.out.println( "dateTime_EastCoastUS: " + dateTime_EastCoastUS );
System.out.println( "date-time in UTC: " + dateTime_EastCoastUS.toDateTime( DateTimeZone.UTC ) );
When run…
dateTime_MyDefaultTimeZone: 2013-12-28T18:51:18.485-08:00
dateTime_EastCoastUS: 2013-12-28T21:51:18.522-05:00
date-time in UTC: 2013-12-29T02:51:18.522Z
It is again this old pitfall with java.util.Date: Its toString()-method which you indirectly use when printing calendar.getTime()
uses your default time zone, not the time zone of your calendar instance (which you set to 'EST').
Solution:
Date currentTime = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy");
sdf.setTimeZone(TimeZone.getTimeZone("America/New_York"));
System.out.println("Current Date & Time: " + sdf.format(currentTime));
Explanations:
a) In first line no calendar instance is necessary because you are just interested in current global time (the same physical time independent from timezone). Calendar.getInstance()
is also more consuming resources. Finally, both expressions new Date()
and Calendar.getInstance(...).getTime()
have no time zone reference when it is about the internal state. Only the toString()
-method of j.u.Date uses default time zone.
b) You need to define an output format which is given in line 2. It is up to you to change it. Just study the pattern documentation of java.text.SimpleDateFormat
.
c) You also need to define the time zone in your output format to help the format object to translate the global Date-instance into a timezone-aware representation. By the way, I had choosen the identifier 'America/New_York', not 'EST' because latter form can be sometimes ambigous. You should either choose the first form (IANA- or Olson time zone identifier) or the form 'GMT+/-HH:mm'.
d) The output itself is done with sdf.format(currentTime)
, not just currentTime
(no implicit call of toString()
).
e) To answer your question 'Is this problem related to daylight time saving ?': No, the time in time zone EST (America/New_York) is never in DST in december.
Conclusion:
If you can, you should try to avoid j.u.Date and j.u.Calendar because there are too many pitfalls. At the moment JodaTime is a better alternative, although not without issues.