I want to perform a date operation in my android app. What I want is to subtract two dates and get the result. But subtraction leads to the wrong result whenever I change the time zone to central daylight time.
I use the following code to find the difference between the two dates.
Long lDateDiff = dtCycleDay.getTime() - m_dtHistory[0].getTime();
lDateDiff = lDateDiff / (1000 * 60 * 60 * 24);
Here in m_dtHistory[0], the date stored is Thu Mar 01 00:00:00 CST 2012.
And in my dtCycleDay variable the date changes from Thu Mar 01 00:00:00 CST 2012, Thu Mar 02 00:00:00 CST 2012, Thu Mar 03 00:00:00 CST 2012... and so on.
Now up to Thu Mar 11 00:00:00 CST 2012, the subtraction result is fine, but when the date changes to Thu Mar 12 00:00:00 CDT 2012, the CST changes to CDT and it show wrong subtraction result.
Why this happens and these happen only when I change the time zone to Central Daylight Time or pacific Daylight Time.
What do you mean by the "wrong" subtraction result?
My guess is that the result is 23 hours or 25 hours- which is exactly what I'd expect when a daylight transition occurs, as the intervening day is longer or shorter in terms of elapsed time. The "longer" day won't be relevant when dividing by 24, but the shorter one will... you're assuming that every day has 24 hours, and that you can therefore count the number of days by dividing the elapsed milliseconds by "the number of milliseconds in 24 hours". That doesn't work due to varying day lengths.
Don't forget that a Date value is purely an instant in time. It doesn't know about calendars or time zones... if you want to know the difference in "local" dates and times (where midnight to midnight is always 24 hours), I'd suggest using Joda Time instead... Date and Calendar don't really do that for you.
If the real problem you're describing is the time zone changing at the wrong date, that's a different matter entirely, and could be due to various different causes. For one thing, you should show exactly which time zone you're talking about: the abbreviations are ambiguous, whereas the tzdb names (e.g. "Europe/Paris") aren't.
Related
I'm parsing a date, "00:45:00 Mar:2017", "01:45:00 Mar:2017" and "02:45:00 Mar:2017".
All of the others give the correct output, besides "01:45:00 Mar:2017", which always rounds to "02:45:00 Mar:2017".
Code
try {
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("hh:mm:dd MMM:yyyy");
Date date = simpleDateFormat.parse("01:45:26 Mar:2017");
System.out.print(date);
} catch (ParseException e) {
System.out.print(e.getMessage());
}
Output from "00:45:26 Mar:2017"
Sun Mar 26 00:45:00 GMT 2017
Output from "01:45:26 Mar:2017"
Sun Mar 26 02:45:00 BST 2017
Output from "02:45:26 Mar:2017"
Sun Mar 26 02:45:00 BST 2017
Day zero?
Your pattern says the third pair of digits is day-of-month (dd) but there cannot be a day number zero as seen in your examples with 00.
I suspect that third pair of digits is actually seconds rather than day-of-month, and that your day-of-month is missing.
UK DST Cutover
Yes indeed, in the UK the Daylight Saving Time (DST) cutover “Spring forward” is 2017-03-29 at 01:00. Described here:
Mar 26, 2017 - Daylight Saving Time Started
When local standard time was about to reach
Sunday, March 26, 2017, 1:00:00 am clocks were turned forward 1 hour to
Sunday, March 26, 2017, 2:00:00 am local daylight time instead
Formatting patterns are case-sensitive
Another problem: You used lowercase hh where you probably should be using uppercase HH for 24-hour clock.
Avoid legacy date-time classes
Also, you are using troublesome old date-time classes that are now legacy. Supplanted by the java.time classes.
Apparently the British clocks change on the 26th of March, at 1:00.
I had a strange behaviour when parsing dates. Given
DateFormat sdf= new SimpleDateFormat("dd/MM/yyyy");
sdf.parse("25/10/2014") returns 25 Oct 2014 00:00:00 BST
while
sdf.parse("27/10/2014") returns 27 Oct 2014 00:00:00 GMT
I figured out that's because of the Daylight Time change, but surely I would expect the same time zone to be returned by the same parser. Or am I wrong?
Per the Wikipedia article on British Summer Time
During British Summer Time (BST), civil time in the United Kingdom is advanced one hour forward of Greenwich Mean Time (GMT), so that evenings have more daylight and mornings have less
BST begins at 01:00 GMT on the last Sunday of March and ends at 01:00 GMT (02:00 BST) on the last Sunday of October.
The last Sunday of October 2014 was the 26th. So, the TimeZone changed from British Summer Time to GMT as observed in the UK.
The default TimeZone is your system TimeZone, so when that changes your parser will too.
From the documentation of SimpleDateFormat#parse(String ParsePosition):
The TimeZone value may be overwritten, depending on the given
pattern and the time zone value in text. Any TimeZone
value that has previously been set by a call to setTimeZone()
may need to be restored for further operations.
So: No, the parser does not always return the same time zone.
I have a Date Object in following:
Date date=new Date("Mon, 05 May 2014 12:31:12 +0000")
I want to get Timestamp of date Object then :
date.getTime()
1399293072000
but this value not correct , correct value in following :
1399276872000
//*** for get timestamp use of http://www.epochconverter.com ***\\
why ?
First things first, from the JavaDoc for Date
Date(String s)
Deprecated.
As of JDK version 1.1, replaced by DateFormat.parse(String s).
So the constructor you are using has been deprecated since 1997!
Next, onto the JavaDoc for Date.parse which the construtor uses:
It accepts many syntaxes; in particular, it recognizes the IETF
standard date syntax: "Sat, 12 Aug 1995 13:30:00 GMT". It also
understands the continental U.S. time-zone abbreviations, but for
general use, a time-zone offset should be used: "Sat, 12 Aug 1995
13:30:00 GMT+0430" (4 hours, 30 minutes west of the Greenwich
meridian). If no time zone is specified, the local time zone is
assumed. GMT and UTC are considered equivalent.
Empathsis mine.
So, what timezone are you in? Presumably not UTC.
You should specify local time zone while constructing Date object
Example:
Date date=new Date("Mon, 05 May 2014 12:31:12 GMT+0530");
Using Mon, 05 May 2014 12:31:12 +0000 at http://www.epochconverter.com I get 1399285872000 which is different from your timestamp.
Or you're passing different values, or there's a bug somewhere or
The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z).
where the javadoc for java.util.Date.getTime() doesn't mention leap seconds.
Date now = new Date();
long timeInterval = now.getTime() - (15705 * 24 * 60 * 60 * 1000L);
long hours = timeInterval / (60 * 60 * 1000L);
LOG.debug(String.format("current date:%s, timeInterval:%d,hours:%d",now.toString(),timeInterval, hours));
The result that system print is(15705 means the number of days since 1970s):
12/12/31 22:06:47 DEBUG stat.TimeTest: current date:Mon Dec 31
22:06:47 CST 2012, timeInterval:50807153, hours:14
You can see the current hour is 21 hours, but the result displays as 14 hours.
Mon Dec 31 22:06:47 CST 2012 is Mon Dec 31 14:06:47 2012 in GMT time, which is the time zone used for the start of the epoch.
In other words, now.getTime() returns the number of milliseconds since January 1, 1970, 00:00:00 GMT and you use a different time zone.
now.getTime() would get you the value in UTC millis - thats GMT+0.
the log print you showed probably uses the system time zone, where it was 22:06:47 and probably wasnt anywhere near england :-)
also, please use the Calendar class for date arithmatic because it, unlike your code, would take into account things like leap years, leap seconds and timezone changes (wehich dont happen in UTC, might mihg thappen in any other zone)
Can someone explain why or if this code is wrong?
// main
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
System.out.println(calendar.getTime());
calendar.add(Calendar.DATE, -1);
System.out.println(calendar.getTime());
calendar.set(Calendar.HOUR_OF_DAY, 0);
System.out.println(calendar.getTime());
It produces:
Fri Jan 28 15:27:35 EST 2011
Thu Jan 27 15:27:35 EST 2011
Wed Jan 26 19:27:35 EST 2011
Am I missing something obvious? I expect to see something like Thu Jan 27 00:27:35 EST 2011
Thanks.
You're printing it out in the default time zone, not UTC. Although your calendar knows the time zone you're interested in, the java.util.Date returned by getTime() doesn't... and Date.toString() uses the system time zone.
Given that you specified in the subject that you wanted 12am in UTC, why would you expect to see Thu Jan 27 00:27:35 EST 2011? EST isn't the same as UTC.
EDIT: As always, I'd just like to point out that Joda Time is generally a much nicer API to use for date/time arithmetic in Java. You're currently getting the right answer, but I'd still recommend moving to Joda :)
EST is UTC - 5 hours, so 19:27 EST corresponds to 00:27 UTC. It seems logical to me.
Use a date format with a UTC locale to display your calendars, instead of using your default locale.
For UTC calculations (only) you might find using long is simpler.
long time = System.currentTimeMillis();
// yesterday at 12:00:00.000 am.
long yesterday = (time / 86400000 - 1) * 86400000;