There is a lot of similar topics but I couldn't find something similar then my problem. I've found only how to calculate if for example second time is greater then first time, like:
22:00
23:00
The result is easy to get. Just subtract second time with first using Date API. Difference is in milliseconds and you can easily convert them in seconds/minutes..
What I want to know, how to get difference between time in first day and time in second day, for example:
22:25
06:30
Difference should be 8 hours and 5 minutes.
Or another example
19:00
00:00
Difference should be 5 hours.
How to calculate time in this way? Any help is appreciated.
Convert your date and time to TimeStamp (It's just the long representation of a date in milliseconds since Jan. 1, 1970.), then calculate difference, and transferred from milliseconds to hours.
Also check this
Use Calendar class. Set your day, hour and minutes and finally subtract those dates (in milliseconds) and you will convert result in hour, minutes and seconds.
Related
I never would believe that this could amount to being such a hassle. I am trying to make a clock that always displays the local time in specific timezones.
My laptop is currently set in GMT0 timezone (UK).
I want to get the milliseconds of the timezone "Europe/Stockholm".
So let's say it's 17:00 here in the UK I would like to get the milliseconds corresponding to 18:00 which would be the Swedish time.
The time in milliseconds as used by Date is independent of the time zone. Only when you print (or parse) a time, you use a DateFormat that is localized, so it ensures you get the time in the specific timezone.
When time is represented as milliseconds (or seconds or nanoseconds, etc), that is almost always milliseconds since some epoch. In the case of unix and java, this is midnight Jan 1, 1970 UTC.
Time zones are generally arranged as a round number of hours relative to UTC. In certain time zones it's not a round hour but 30 minutes, 15 minutes or 45 minutes from a round hour.
Nevertheless, for any time unit below a minute, all those time zones match UTC exactly.
Therefore, whatever the current second or millisecond is in Sweden, it is the same as it is, for example, in Nepal, whose time zone is 5:45 minutes from UTC.
When you work with an object that allows you to retrieve the separate fields of the given time, the milliseconds field will usually reflect just the number of milliseconds since the beginning of the current second, not the number of milliseconds since midnight. Therefore it will never be more than 999, and it will be the same the world over.
After reading the answers here and discovering another route, this is what finally worked for me.
DateTime curDateTime = new DateTime();
int offset = DateTimeZone.forID("Europe/Stockholm").getOffset(curDateTime.getMillis());
long milli = (curDateTime.getMillis()+offset);
I have two longs representing time since the epoch. They both have the same timezone. I want to find the difference in seconds between these two times, respecting day light savings.
(def a (java.util.Date. 1259568796000)) ;; Before Day Light Savings
(def b (java.util.Date. 1255147200000)) ;; After Day Light Savings
Where 'a' is 2009-11-30T08:13:16.000-00:00
and
Where 'b' is 2009-10-10T04:00:00.000-00:00
Using JodaTime, I can make an Interval out of these two times, turn them into a Duration, and get the StandardSeconds.
(.getStandardSeconds (.toDuration (Interval. a b)))
This doesn't work though, because the docs for Period indicate that Duration will mess up Day Light Savings:
When this time period is added to an instant, the effect is of adding
each field in turn. As a result, this takes into account daylight
savings time. Adding a time period of 1 day to the day before daylight
savings starts will only add 23 hours rather than 24 to ensure that
the time remains the same. If this is not the behaviour you want, then
see Duration.
How can I accomplish this task?
The long in Java represents a certain point in time (milliseconds since midnight on 1.1.1970, ignoring leap seconds). They don't carry a time zone and do not switch with daylight savings time, it is always expressed in UTC. To find the difference in seconds between two such timepoints you can use
(secondTime - firstTime) / 1000
The two times you have given are expressed in GMT, i.e.
1259568796000 = 2009-11-30T08:13:16.000-00:00 GMT
1255147200000 = 2009-10-10T04:00:00.000-00:00 GMT
And GMT does not switch to daylight savings time either. Maybe you were confused by that.
The java.util.Calendar class has support for daylight savings. Perhaps run your dates through that first? It should do the normalization for you. Check out this other post.
I need to determine if a time stamp is an exact hour (i.e. it represents a time with no minutes, seconds or milliseconds components) - using primitives only. The code is called several hundred times per second and I don't want the overhead of a Calendar or other object.
I've tried this but rounding errors cause the comparison to fail.
float hours = (time / 3600000f);
boolean isExactHour = hours == (int)hours;
For example, if time = 1373763600470, hours = 381601.03125. That time stamp represents 01:00:00:000 GMT today and hours should be 381601.
Any ideas for a quick and simple way to do this? Thanks!
[EDIT]
It seems that this is more complex than at first sight (when is it not? :)
For clarity, I don't care about time zones, nor leap seconds. The time stamp is generated by a method which returns the previous midnight - i.e. 13 July 2013 00:00:00:000 for today. I am then calculating, for any time stamp in an array of longs which is always this initial time stamp plus/minus an exact multiple of 5 minutes. My aim to to determine if a given stamp is "top of the hour". I might have edge cases where the multiple of 5 minutes overlaps a year end but I can live with those.
(time % 36000000) == 0
Surely this is obvious?
EDIT
To get accuracy w.r.t. leap seconds, assuming a lookup table of leap seconds indexed by year since (say) 1970, something like:
((time-leapSeconds[(int)(time/(1000*60*60*24*365.2425))-1970]*1000) % 3600000) == 0
Programmers needing this level of accuracy should also see all of Einar's comments below.
I want to calculate the number of days from the "beginning of time" to a current date. This could be easily achieved with a simple calculation (timestamp / 24 / 60 / 60 / 1000 = daysFromBeginningOfTime) but the twist is that i need to be aware of time zones as well. The timestamp is the same everywhere in the world but when you parse it with the proper time zone then it reflects the differences between locations so using just the timestamp doesn't work and i don't want to handle all the time zone transitions myself.
Example:
if it's 23:30 in London and the day number is 18843 then in Amsterdam it's 0:30 and the day number should be 18844.
I looked at joda.time but didn't really find what i was looking for.
Anyone have any ideas?
The problem appears due to a wrong initial assumption, I think.
The argument the OP makes in his example is not correct. No matter what the clock shows in London or Amsterdam, the time difference to the start of the epoch is - at every point of time - independent of where you are in the world.
Hence, the solution is to parse a given input date to an UTC timestamp and proceed as before.
(Ignoring the point that zero is not "the beginning of time" ... and that the actual time point for the beginning of time is probably unknowable ...)
Here's how to calculate the number of days since "the local-time UNIX epoch in a given timezone"1.
Get hold of the object that represents the local timezone.
Get the timezone's offset from the object
Convert it to milliseconds and add it to the current UTC time.
Calculate the day number as before.
1 - ... whatever that means.
I am using an API which requires a date parameter as a number of seconds, an int.
My problem is that I currently store this time in java.util.date and I was wondering if there is some way to convert the java.util.date variable to seconds so that I can fit it into the int parameter which the API requires?
import java.util.Date;
...
long secs = (new Date().getTime())/1000;
...
Please see - http://docs.oracle.com/javase/6/docs/api/java/util/Date.html#getTime()
Since Java 8 and onwards there's this elegant method which returns the Epoch time in seconds (seconds since 0:00:0 January 1st 1970). You can then store this value as an numeric value: a "long" in this case.
long timestamp = java.time.Instant.now().getEpochSecond();
java.util.Date.getTime() it returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object.
java.util.Date date=new Date();
System.out.println(date.getTime());
Output:
1340128712111
To get seconds from milliseconds you need to divide it by 1000.
long secs = date.getTime()/1000;
System.out.println(secs);
Output:
1340128712
Alternatively Instant.getEpochSecond() returns the number of seconds from the Java epoch of 1970-01-01T00:00:00Z. Its available since Java v1.8 docs.
Number of seconds by itself doesn't mean much. Number of seconds within the current minute? Number of seconds since 0:00:00 Janurary 1st, 1970? Number of seconds since lunch? Could you be more specific.
Put it into the API also doesn't mean much, unless you specify exactly which API you are using, and where you are attempting to put these seconds.