Program followed by output. Someone please explain to me why 10,000,000 milliseconds from Jan 1, 1970 is November 31, 1969. Well, someone please explain what's wrong with my assumption that the first test should produce a time 10,000,000 milliseconds from Jan 1, 1970. Numbers smaller than 10,000,000 produce the same result.
public static void main(String[] args) {
String x = "10000000";
long l = new Long(x).longValue();
System.out.println("Long value: " + l);
Calendar c = new GregorianCalendar();
c.setTimeInMillis(l);
System.out.println("Calendar time in Millis: " + c.getTimeInMillis());
String origDate = c.get(Calendar.YEAR) + "-" + c.get(Calendar.MONTH) + "-" + c.get(Calendar.DAY_OF_MONTH);
System.out.println("Date in YYYY-MM-DD format: " + origDate);
x = "1000000000000";
l = new Long(x).longValue();
System.out.println("\nLong value: " + l);
c.setTimeInMillis(l);
System.out.println("Calendar time in Millis: " + c.getTimeInMillis());
origDate = c.get(Calendar.YEAR) + "-" + c.get(Calendar.MONTH) + "-" + c.get(Calendar.DAY_OF_MONTH);
System.out.println("Date in YYYY-MM-DD format: " + origDate);
}
Long value: 10000000
Calendar time in Millis: 10000000
Date in YYYY-MM-DD format: 1969-11-31
Long value: 1000000000000
Calendar time in Millis: 1000000000000
Date in YYYY-MM-DD format: 2001-8-8
The dates you print from Calendar are local to your timezone, whereas the epoch is defined to be midnight of 1970-01-01 in UTC. So if you live in a timezone west of UTC, then your date will show up as 1969-12-31, even though (in UTC) it's still 1970-01-01.
First, c.get(Calendar.MONTH) returns 0 for Jan, 1 for Feb, etc.
Second, use DateFormat to output dates.
Third, your problems are a great example of how awkward Java's Date API is. Use Joda Time API if you can. It will make your life somewhat easier.
Here's a better example of your code, which indicates the timezone:
public static void main(String[] args) {
final DateFormat dateFormat = SimpleDateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL);
long l = 10000000L;
System.out.println("Long value: " + l);
Calendar c = new GregorianCalendar();
c.setTimeInMillis(l);
System.out.println("Date: " + dateFormat.format(c.getTime()));
l = 1000000000000L;
System.out.println("\nLong value: " + l);
c.setTimeInMillis(l);
System.out.println("Date: " + dateFormat.format(c.getTime()));
}
Calendar#setTimeInMillis() sets the calendar's time to the number of milliseconds after Jan 1, 1970 GMT.
Calendar#get() returns the requested field adjusted for the calendar's timezone which, by default, is your machine's local timezone.
This should work as you expect if you specify "GMT" timezone when you construct the calendar:
Calendar c = new GregorianCalendar(TimeZone.getTimeZone("GMT"));
Sadly, java.util.Date and java.util.Calendar were poorly designed leading to this sort of confusion.
Your timezone is most likely lagging behind GMT (e.g., GMT-5), therefore 10,000,000ms from epoch is December 31 1969 in your timezone, but since months are zero-based in java.util.Calendar your Calendar-to-text conversion is flawed and you get 1969-11-31 instead of the expected 1969-12-31.
You can figure out yourself if you change your first c.setTimeInMillis(l); in c.clear();
Related
I am trying to convert locale time to UTC, and then UTC to locale time. But I am not getting the result.
public class DateDemo
{
public static void main(String args[])
{
DateFormat dateFormatter =
DateFormat.getDateTimeInstance
(DateFormat.SHORT, DateFormat.SHORT, Locale.getDefault());
TimeZone.setDefault(TimeZone.getDefault());
SimpleDateFormat simpleDateFormatter = new SimpleDateFormat("dd/MM/yyyy");
SimpleDateFormat simpleTimeFormatter = new SimpleDateFormat("hh:mm:ss a");
Date today = new Date();
String localeFormattedInTime = dateFormatter.format(today);
try
{
Date parsedDate = dateFormatter.parse(localeFormattedInTime);
System.out.println("Locale:" + localeFormattedInTime);
System.out.println("After parsing a date: " + parsedDate);
simpleDateFormatter.setTimeZone(TimeZone.getDefault());
simpleTimeFormatter.setTimeZone(TimeZone.getDefault());
String date = simpleDateFormatter.format(today);
String time = simpleTimeFormatter.format(today);
System.out.println("Today's only date: " + date);
System.out.println("Today's only time: " + time);
//// Locale to UTC converting
simpleDateFormatter.setTimeZone(TimeZone.getTimeZone("UTC"));
simpleTimeFormatter.setTimeZone(TimeZone.getTimeZone("UTC"));
String utcDate = simpleDateFormatter.format(today);
String utcTime = simpleTimeFormatter.format(today);
System.out.println("Convert into UTC's date: " + utcDate);
System.out.println("Convert into UTC's only time: " + utcTime);
//// UTC to locale converting
simpleDateFormatter.setTimeZone(TimeZone.getDefault());
simpleTimeFormatter.setTimeZone(TimeZone.getDefault());
Date getDate = simpleDateFormatter.parse(utcDate);
Date getTime = simpleTimeFormatter.parse(utcTime);
String getLocalDate = simpleDateFormatter.format(getDate);
String getLocalTime = simpleTimeFormatter.format(getTime);
System.out.println("Get local date: " + getLocalDate);
System.out.println("Get local time: " + getLocalTime);
} catch (ParseException e) {
e.printStackTrace();
}
}
}
I am sending local date & time to the web service, and then when require I need to retrieve the UTC date & time and then convert into locale date & time (i.e. user's local settings).
Sample Output:
Locale:11/9/12 8:15 PM
After parsing a date: Fri Nov 09 20:15:00 SGT 2012
Today's only date: 09/11/2012
Today's only time: 08:15:30 PM
Convert into UTC's date: 09/11/2012
Convert into UTC's only time: 12:15:30 PM
Get local date: 09/11/2012
Get local time: 12:15:30 PM
After Saksak & ADTC answers:
For the code fragment, UTC date & time (what is actually coming as GMT-5 because database may be in USA) is the input, and I want to get local date & time as output. But this following segment is still giving GMT-5 time.
SimpleDateFormat simpleDateTimeFormatter = new SimpleDateFormat("dd/MM/yyyy hh:mm:ss a");
....
Date inDateTime = simpleDateTimeFormatter.parse(intent.getExtras().getString("inTime")); Date outDateTime = simpleDateTimeFormatter.parse(intent.getExtras().getString("outTime"));
simpleDateTimeFormatter.setTimeZone(TimeZone.getDefault()); simpleDateTimeFormatter.setTimeZone(simpleDateTimeFormatter.getTimeZone());
//TimeZone tzTimeZone = TimeZone.getDefault();
//System.out.println("Current time zone: " + tzTimeZone.getDisplayName());
String getLocalInTimeString = simpleDateTimeFormatter.format(inDateTime);
String getLocalOutTimeString = simpleDateTimeFormatter.format(outDateTime);
My question: getLocalInTimeString & getLocalOutTimeString still showing GMT-5 timing. What's wrong here? Do I need to set any other things?
What you need to do to solve your problem is the following, you have your code to convert back to local time in this order :
simpleDateFormatter.setTimeZone(TimeZone.getDefault());
simpleTimeFormatter.setTimeZone(TimeZone.getDefault());
Date getDate = simpleDateFormatter.parse(utcDate);
Date getTime = simpleTimeFormatter.parse(utcTime);
and what you need to do is wait until you parse utcDate, utcTime Strings back to Date Object
then set the date formatter time zone to local zone as follows :
Date getDate = simpleDateFormatter.parse(utcDate);
Date getTime = simpleTimeFormatter.parse(utcTime);
simpleDateFormatter.setTimeZone(TimeZone.getDefault());
simpleTimeFormatter.setTimeZone(TimeZone.getDefault());
this should print the correct date/time in local.
Edit:
here is the full main method :
public static void main(String[] args) {
DateFormat dateFormatter = DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT, Locale.getDefault());
TimeZone.setDefault(TimeZone.getDefault());
SimpleDateFormat simpleDateFormatter = new SimpleDateFormat("dd/MM/yyyy");
SimpleDateFormat simpleTimeFormatter = new SimpleDateFormat("hh:mm:ss a");
Date today = new Date();
String localeFormattedInTime = dateFormatter.format(today);
try {
Date parsedDate = dateFormatter.parse(localeFormattedInTime);
System.out.println("Locale:" + localeFormattedInTime);
System.out.println("After parsing a date: " + parsedDate);
simpleDateFormatter.setTimeZone(TimeZone.getDefault());
simpleTimeFormatter.setTimeZone(TimeZone.getDefault());
String date = simpleDateFormatter.format(today);
String time = simpleTimeFormatter.format(today);
System.out.println("Today's only date: " + date);
System.out.println("Today's only time: " + time);
//// Locale to UTC converting
System.out.println("TimeZone.getDefault() >>> " + TimeZone.getDefault());
simpleDateFormatter.setTimeZone(TimeZone.getTimeZone("UTC"));
simpleTimeFormatter.setTimeZone(TimeZone.getTimeZone("UTC"));
String utcDate = simpleDateFormatter.format(today);
String utcTime = simpleTimeFormatter.format(today);
System.out.println("Convert into UTC's date: " + utcDate);
System.out.println("Convert into UTC's only time: " + utcTime);
//// UTC to locale converting
/**
** //////EDIT
*/
// at this point your utcDate,utcTime are strings that are formated in UTC
// so first you need to parse them back to Dates using UTC format not Locale
Date getDate = simpleDateFormatter.parse(utcDate);
Date getTime = simpleTimeFormatter.parse(utcTime);
// NOW after having the Dates you can change the formatters timezone to your
// local to format them into strings
simpleDateFormatter.setTimeZone(TimeZone.getDefault());
simpleTimeFormatter.setTimeZone(TimeZone.getDefault());
String getLocalDate = simpleDateFormatter.format(getDate);
String getLocalTime = simpleTimeFormatter.format(getTime);
System.out.println("Get local date: " + getLocalDate);
System.out.println("Get local time: " + getLocalTime);
} catch (ParseException e) {
e.printStackTrace();
}
}
Your problem is in lines 54 and 55:
Date getDate = simpleDateFormatter.parse(utcDate);
Date getTime = simpleTimeFormatter.parse(utcTime);
These lines are merely parsing Strings that contain the date and time, but these strings do not have any timezone information:
utcDate = "09/11/2012"
utcTime = "12:15:30 PM"
Therefore the parser assumes that the Strings are already in the locale of the timezone you set in lines 51 and 52.
Now think about how to fix it ;) HINT: Make sure the parser is assuming the correct timezone of the time represented by the strings.
PS: [RESOLVED!] I solved the problem but I discovered that the timezone conversion is erratic, for at least where I am. Time is 8:30 pm local. Convert to UTC, 12:30 pm (correct, 8 hr difference). Convert back, it's 8:00 pm (WRONG, eventhough the set timezone is correct - I got the original one and passed it back in - I'm only getting 7.5 hour difference). You should look for more reliable ways unless you can figure out what's going on and how to solve it.
[RESOLUTION:] The problem above was actually because the original code was splitting the date and time into two different parsers. If you use just one parser for both date and time combined you will get the correct date and time in the target locale. So in conclusion the parser is reliable but the way you use it makes a big difference!
SimpleDateFormat simpleDateTimeFormatter
= new SimpleDateFormat("dd/MM/yyyy hh:mm:ss a");
Date getDateTime
= simpleDateTimeFormatter.parse(utcDate + " " + utcTime);
//use above line if you have the date and time as separate strings
simpleDateTimeFormatter.setTimeZone(TimeZone.getDefault());
String getLocalDateTime = simpleDateTimeFormatter.format(getDateTime);
System.out.println("Get local date time: " + getLocalDateTime);
WHY USING TWO SEPARATE PARSERS FOR DATE AND TIME IS UNRELIABLE:
As explained above, it's a bad idea to use two separate parsers for date and time parts. Here's why:
Date getDate = simpleDateFormatter.parse(utcDate);
Date getTime = simpleTimeFormatter.parse(utcTime);
//Time zone changed to local here
String getLocalDate2 = simpleDateTimeFormatter.format(getDate);
String getLocalTime2 = simpleDateTimeFormatter.format(getTime);
System.out.println("Get local date2: " + getLocalDate2);
System.out.println("Get local time2: " + getLocalTime2);
OUTPUT:
Get local date2: 10/11/2012 08:00:00 AM
Get local time2: 01/01/1970 10:35:10 AM
I get the half hour difference because the default date 01/01/1970 is used in the Date variable storing time (second line). When this is converted to local timezone, the error happens as the formatter bases its conversion on the default date 01/01/1970 (where I live, the time difference was +7.5 hours in 1970 - today, it is +8 hours). This is why two separate parsers is not reliable even if you get the right result and you must always use a combined parser that accepts both date and time information.
I've below code in Java 1.7:
DateFormat df = DateFormat.getInstance();
Date startDate = df.parse("07/28/12 01:00 AM, PST");
The above date time (07/28/12 01:00 AM, PST) is in the properties file which is configurable. If this date time is already passed, then I need to get the current date, set the time part from above string which is 01:00 AM PST in the current date & if this time is also already passed, then get the next day & set the time part from above string in it. The final object should be Date since I need to use it in Timer object.
How can I do this efficiently? Should I convert from date to Calendar or vice-versa? Can any one provide snippet?
You should look into the Calendar class. You can use constructs like:
Calendar cal = Calendar.getInstance();
cal.setTime(startDate);
cal.add(Calendar.DAY_OF_YEAR, 1);
It also has methods for checking if your startDate is before() or after() a new date (use the current time).
While writing of the built-in Java date/time structure, i would be remiss if i didnt plug Joda Time, considered by many to be superior to the native Java implementation.
EDIT:
It would be more efficient to show an example of the Date.compareTo() process, as the Calendar.before() and Calendar.after() require comparisons against other Calendar objects, which can be expensive to create.
take a look at the following:
DateFormat df = DateFormat.getInstance();
Date startDate = df.parse("07/28/12 01:00 AM, PST");
Calendar cal = Calendar.getInstance();
cal.setTime(startDate);
Date now = new Date();
if (startDate.compareTo(now)< 0) {
System.out.println("start date: " + startDate + " is before " + now);
Calendar nowCal = Calendar.getInstance();
nowCal.add(Calendar.DAY_OF_YEAR,1);
cal.set(Calendar.DAY_OF_YEAR, nowCal.get(Calendar.DAY_OF_YEAR));
} else if (startDate.compareTo(now) == 0) {
System.out.println("startDate: " +startDate + " is equal to " + now);
} else {
System.out.println("startDate: " + cal + " is after " + now);
}
System.out.println(cal.getTime());
I think this should work...your algorthim has my head spinning a little and I'm in a different time zone, so you original string didn't work :P
try {
DateFormat df = DateFormat.getInstance();
Date startDate = df.parse("28/07/2012 01:00 AM");
System.out.println("StartDate = " + startDate);
Date callDate = startDate;
Calendar today = Calendar.getInstance();
Calendar start = Calendar.getInstance();
start.setTime(startDate);
System.out.println("Today = " + today.getTime());
// If this date time is already passed
// Tue Jul 31 12:18:09 EST 2012 is after Sat Jul 28 01:00:00 EST 2012
if (today.after(start)) {
//then I need to get the current date, set the time part from above string in the current date
Calendar timeMatch = Calendar.getInstance();
timeMatch.setTime(startDate);
timeMatch.set(Calendar.DATE, today.get(Calendar.DATE));
timeMatch.set(Calendar.MONTH, today.get(Calendar.MONTH));
timeMatch.set(Calendar.YEAR, today.get(Calendar.YEAR));
//& if this time is also already passed, then get the next day & set the time part from above string in it
if (timeMatch.after(today)) {
timeMatch.add(Calendar.DATE, 1);
}
callDate = timeMatch.getTime();
}
System.out.println("CallDate = " + callDate);
} catch (ParseException exp) {
exp.printStackTrace();
}
This produces the following output
StartDate = Sat Jul 28 01:00:00 EST 2012
Today = Tue Jul 31 12:18:09 EST 2012
CallDate = Tue Jul 31 01:00:00 EST 2012
i'm having a problem while converting Timestamp objects to joda's LocalTime.
See example below:
public static void main(String[] args) {
Timestamp t = Timestamp.valueOf("1111-11-11 00:00:00");
System.out.println(t); //-- prints '1111-11-11 00:00:00.0'
System.out.println(new LocalDate(t)); //-- prints '1111-11-17'
Calendar calendar = Calendar.getInstance();
calendar.setTime(t);
System.out.println(LocalDate.fromCalendarFields(calendar)); //-- prints '1111-11-11'
}
I could not determine why 'new LocalDate(t)' results in '1111-11-17'. Can anyone help me on that?
I notice this "problem" while using joda-time-hibernate to populate my bean's property of type LocalDate.
This indeed has to do with the different types of calendars. java.sql.Timestamp, like java.util.Date, don't have any calendar information, as they are stored solely as a number, the number of milliseconds since 1970, with the implied assumption that there was a jump between October 4 and October 15 1582, when the Gregorian calendar was officially adopted, replacing the old Julian calendar. So, you can't possibly have a Date (or Timestamp) object representing October 7, 1582. If you try to create such a date, you'll automatically end up 10 days later. For example:
Calendar c = Calendar.getInstance();
c.setTimeZone(TimeZone.getTimeZone("UTC"));
c.set(1582, Calendar.OCTOBER, 7, 0, 0, 0);
c.set(Calendar.MILLISECOND, 0);
d = c.getTime();
System.out.println("Date: " + d);
// Prints:
// Date: Sun Oct 17 00:00:00 GMT 1582
In other words, Date objects have an implied Julian+Gregorian chronology, automatically switching between those two.
JodaTime is a bit smarter, it supports several Chronologies, including a continuing Julian, a proleptic Gregorian, a mixed Julian+Gregorian, and a standard ISO Chronology which is almost identical to the Gregorian one. If you read the JavaDoc of the LocalDate.fromCalendarFields method, you'll see that it mentions that:
This factory method ignores the type of the calendar and always creates a LocalDate with ISO chronology.
The mixed Julian+Gregorian chronology behaves like the implicit Java dates, with an automatic switch between the two different calendars. The pure chronologies assume that their calendar system is forever in use, so for example it assumes that the Gregorian calendar has been used since the start of time.
Let's see how each Chronology treats the 1111-11-11 date:
Calendar c = Calendar.getInstance();
c.setTimeZone(TimeZone.getTimeZone("UTC"));
c.set(1111, Calendar.NOVEMBER, 11, 0, 0, 0);
c.set(Calendar.MILLISECOND, 0);
Date d = c.getTime();
System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));
Ends up as:
Date: Sat Nov 11 00:00:00 GMT 1111 (-27079747200000 milliseconds)
ISO: 1111-11-18T00:00:00.000Z
Julian+Gregorian: 1111-11-11T00:00:00.000Z
Julian: 1111-11-11T00:00:00.000Z
Gregorian: 1111-11-18T00:00:00.000Z
As you can see, the two modern chronologies (ISO and Gregorian) report the correct date if they would have been in use since from the start, while the two that use the Julian calendar report the date as it was known back then, although in hindsight we know it to be off by 7 days compared to the true equinox date.
Let's see what happened around the switch:
c.set(1582, Calendar.OCTOBER, 15, 0, 0, 0);
d = c.getTime();
System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));
ends up as:
Date: Fri Oct 15 00:00:00 GMT 1582 (-12219292800000 milliseconds)
ISO: 1582-10-15T00:00:00.000Z
Julian+Gregorian: 1582-10-15T00:00:00.000Z
Julian: 1582-10-05T00:00:00.000Z
Gregorian: 1582-10-15T00:00:00.000Z
So the only one that's left behind is the Julian calendar. That was a valid date in all the countries that didn't accept the Gregorian calendar yet, which back then was a lot of countries. Greece made the switch in 1923...
One millisecond before that, the date was:
c.add(Calendar.MILLISECOND, -1);
d = c.getTime();
System.out.println("Date: " + d + " (" + d.getTime() + " milliseconds)");
System.out.println("ISO: " + new DateTime(d, ISOChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian+Gregorian: " + new DateTime(d, GJChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Julian: " + new DateTime(d, JulianChronology.getInstance(DateTimeZone.forID("UTC"))));
System.out.println("Gregorian: " + new DateTime(d, GregorianChronology.getInstance(DateTimeZone.forID("UTC"))));
Meaning:
Date: Thu Oct 04 23:59:59 GMT 1582 (-12219292800001 milliseconds)
ISO: 1582-10-14T23:59:59.999Z
Julian+Gregorian: 1582-10-04T23:59:59.999Z
Julian: 1582-10-04T23:59:59.999Z
Gregorian: 1582-10-14T23:59:59.999Z
The ISO and Gregorian chronologies report a date that didn't actually exist in the Gregorian calendar, since there was no Gregorian calendar before October 15, yet this date is valid in an extended, proleptic Gregorian calendar. It's like finding a BCE date inscribed on a BCE monument... Nobody knew that they were before Christ before Christ was even born.
So, the root of the problem is that a date string is ambiguous, since you don't know in which calendar you're measuring. Is the year 5772 a year in the future, or is it the current Hebrew year? Java assumes a mixed Julian+Gregorian calendar. JodaTime provides extensive support for different calendars, and by default it assumes the ISO8601 chronology. Your date is automatically converted from the Julian calendar in use in 1111 to the ISO chronology that we currently use. If you want your JodaTime-enhanced timestamps to use the same chronology as the java.sql.Timestamp class, then explicitly select the GJChronology when constructing JodaTime objects.
The reason this is happening for dates several centuries in the past has to do with the (worldwide) switch to the Gregorian Calendar from the Julian Calendar. Basically, as countries implemented the new calendar system in a piecemeal fashion, they would lose days or weeks (and in some cases, months) in the process. In Spain, for example, 4 October 1582 in the Julian calendar was followed immediately by 15 October 1582 in the Gregorian calendar. Wikipedia has a decent discussion of the topic.
As long as your application does not deal with dates too far in the past, you won't have to deal with discrepancies related to this. As you mentioned in your comment, System.out.println(new LocalDate(Timestamp.valueOf("1999-11-11 00:00:00"))) correctly outputted 1999-11-11. If you need to work with these older dates, I'd suggest looking into an alternative date for the Julian calendar.
(As an aside, I'd be curious to see what would happen if you asked for the local date, in Spain, of 5 October 1582 ... a day which never happened.)
Using java.util.Calendar to add a single day to a Date, and SimpleDateFormat to display the result, sometimes seems to lose a day (generally in March) and sometimes skips a day (in November).
The program below, with output, illustrates the issue. Notice that I'm just adding one day at a time, then skipping a few months and adding a few more days. You'll see that 2008-03-09 gets printed twice, but 2008-11-02 is skipped. The same thing happens in other years, but on different days. I had to experiment to find the days that cause the problem.
If I don't set the timezone to UTC in the SimpleDateFormat then the problem does not occur. I ran this on a machine in the US Central Time Zone.
This certainly looks like a bug in Calendar or SimpleDateFormat, but I have not been able to find it documented anywhere. Anybody have an explanation of what is happening here?
The program:
package mab;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
public class CalendarHiccup2 {
public static void main(String[] args) {
addDays("2008-03-08");
addDays("2009-03-07");
addDays("2010-03-13");
}
public static void addDays(String dateString) {
System.out.println("Got dateString: " + dateString);
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
Calendar calendar = Calendar.getInstance();
try {
calendar.setTime(sdf.parse(dateString));
Date day1 = calendar.getTime();
System.out.println(" day1 = " + sdf.format(day1));
calendar.add(java.util.Calendar.DAY_OF_MONTH, 1);
Date day2 = calendar.getTime();
System.out.println(" day2 = " + sdf.format(day2));
calendar.add(java.util.Calendar.DAY_OF_MONTH, 1);
Date day3 = calendar.getTime();
System.out.println(" day3 = " + sdf.format(day3));
calendar.add(java.util.Calendar.DAY_OF_MONTH, 1);
Date day4 = calendar.getTime();
System.out.println(" day4 = " + sdf.format(day4));
// Skipping a few days ahead:
calendar.add(java.util.Calendar.DAY_OF_MONTH, 235);
Date day5 = calendar.getTime();
System.out.println(" day5 = " + sdf.format(day5));
calendar.add(java.util.Calendar.DAY_OF_MONTH, 1);
Date day6 = calendar.getTime();
System.out.println(" day6 = " + sdf.format(day6));
calendar.add(java.util.Calendar.DAY_OF_MONTH, 1);
Date day7 = calendar.getTime();
System.out.println(" day7 = " + sdf.format(day7));
calendar.add(java.util.Calendar.DAY_OF_MONTH, 1);
Date day8 = calendar.getTime();
System.out.println(" day8 = " + sdf.format(day8));
} catch (Exception e) {
}
}
}
The output:
Got dateString: 2008-03-08
day1 = 2008-03-08
day2 = 2008-03-09
day3 = 2008-03-09
day4 = 2008-03-10
day5 = 2008-10-31
day6 = 2008-11-01
day7 = 2008-11-03
day8 = 2008-11-04
Got dateString: 2009-03-07
day1 = 2009-03-07
day2 = 2009-03-08
day3 = 2009-03-08
day4 = 2009-03-09
day5 = 2009-10-30
day6 = 2009-10-31
day7 = 2009-11-02
day8 = 2009-11-03
Got dateString: 2010-03-13
day1 = 2010-03-13
day2 = 2010-03-14
day3 = 2010-03-14
day4 = 2010-03-15
day5 = 2010-11-05
day6 = 2010-11-06
day7 = 2010-11-08
day8 = 2010-11-09
This is caused by the daylight saving time and is completely correct.
The time (on north hemisphere) is advanced one hour typically in March and moved back in November.
It looks more like a day light saving time issue, which changes in Mar and Nov. Can you try setting the time element to 00:00:00? If you do,
addDays("2008-03-08 00:00:00");
addDays("2009-03-07 00:00:00");
addDays("2010-03-13 00:00:00");
and change the format to,
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
you'll see the difference it makes in the time elements.
When you have these kind of issues you have to print the Calendar and Date instances to figure out what's going on.
The following:
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
changes the time of your Calendar depending on your JVM local time (and timezone). Calendar.getInstance(); creates a Calendar in your JVM local time, when you do calendar.setTime(sdf.parse(".....")) that sets the time in UTC (given how you created the sdf!). Depending on the DoY (and the Year as well!) that can make you pass the midnight and when you print your Date with the yyyy-MM-dd format you see the one day difference.
Print the full Calendar and full Date and you'll figure out what's going on!
Daylight Saving Time
The answer by Tomasz Nurkiewicz is correct, the problem is Daylight Saving Time (DST).
the local time changes at 02:00 local standard time to 03:00 local daylight time on the second Sunday in March and returns at 02:00 local daylight time to 01:00 local standard time on the first Sunday in November.
See Wikipedia on Central Time Zone
Joda-Time
The Joda-Time library makes this kind of work much easier.
A DateTime in Joda-Time knows its own time zone. To use UTC/GMT (no time offset), pass the built-in constant DateTimeZone.UTC.
To print out only the date portion of a date-time, use a DateTimeFormatter.
// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.
// import org.joda.time.*;
// import org.joda.time.format.*;
String dateString = "2008-03-08";
// withTimeAtStartOfDay() is probably superfluous in this example, but I like that it self-documents our focus on the day rather than a particular time of day.
DateTime dateTime = new DateTime( dateString, DateTimeZone.UTC ).withTimeAtStartOfDay();
DateTime dateTimePlus1 = dateTime.plusDays( 1 ).withTimeAtStartOfDay();
DateTime dateTimePlus2 = dateTime.plusDays( 2 ).withTimeAtStartOfDay();
DateTime dateTimePlus3 = dateTime.plusDays( 3 ).withTimeAtStartOfDay();
Dump to console…
System.out.println("dateTime: " + dateTime );
System.out.println("dateTime (date portion): " + ISODateTimeFormat.date().withZone( DateTimeZone.UTC ).print( dateTime ) );
System.out.println("dateTimePlus1: " + dateTimePlus1 );
System.out.println("dateTimePlus2: " + dateTimePlus2 );
System.out.println("dateTimePlus3: " + dateTimePlus3 );
When run…
dateTime: 2008-03-08T00:00:00.000Z
dateTime (date portion): 2008-03-08
dateTimePlus1: 2008-03-09T00:00:00.000Z
dateTimePlus2: 2008-03-10T00:00:00.000Z
dateTimePlus3: 2008-03-11T00:00:00.000Z
Here is the code, for your viewing pleasure:
public static void main(String[] args) throws Exception {
Calendar cal = Calendar.getInstance();
cal.set(2010, Calendar.JULY, 10, 1, 0, 20);
Date d1 = cal.getTime();
Date d2 = new Date();
int seconds = 22;
d2.setTime(d1.getTime() - seconds*1000);
SimpleDateFormat iso_format = new SimpleDateFormat("yyyy-MM-dd kk:mm:ss");
System.out.println(iso_format.format(d1) + " - " + seconds + "s = " + iso_format.format(d2));
}
Output: 2010-07-10 01:00:20 - 22s = 2010-07-10 24:59:58
Shouldn't the answer be 2010-07-09 24:59:58? Why does it loop back to the same day? Is there a way to fix it?
the hour 24 (since you used 'kk' to format) is considered the next day, ie the 10th. it is equivalent to midnight. I use 'HH' to format hours, which would display the 24th hour as '00'. this makes more sense to me and i believe is more standards compliant.
the date changes over at the 00/24th hour. if you were to subtract another hour from the resulting date, the date would become the 9th as expected.
also, if you want true ISO time format 'HH' is better than 'kk'.
http://en.wikipedia.org/wiki/ISO_8601#Times