I have a timestamp object and need to get the milliseconds from it, can someone help me with an example code snippet ?
You can use Timestamp.getTime()
Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT
represented by this Timestamp object.
Example:
long timeInMilliSeconds = t.getTime();
// do magic trick here
Note: Timestamp is extend from Date.
You can just call getTime() to get milliseconds since the Unix epoch. Is that what you were after, or did you want "milliseconds within the second" or something similar?
Note that using just milliseconds is slightly odd for a Timestamp, given that it's designed specifically to be precise to the nanosecond. So you should usually be using getTime() in conjunction with getNanos().
From the Java Docu (link):
public long getTime()
Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Timestamp object.
I guess this will give the output you want.
public void timeInMills(Timestamp t){
System.out.println("Time in Milli second "+t.getTime());
}
Related
I'm trying to get the time differente between two Time vars like this
long timeDiffLong = hFim.getTime() - hInic.getTime();
Time timeDiff = new Time(timeDiffLong);
The output is comming something like this
hFim = 17:30:00
hInic = 17:00:00
timeDiff = 20:30:00
instead of just showing 00:30:00 i always get 20h plus the result
If you use Java 8, you can do:
LocalTime from = hFim.toLocalTime();
LocalTime to = hInic.toLocalTime();
Duration d = Duration.between(from, to);
You can then query the hour/minute etc. with e.g. d.toMinutes().
By doing this
Time timeDiff = new Time(timeDiffLong);
you create a new time object, with timeDiffLong being the milliseconds since 1970-01-01 00:00 UTC. Since the difference is 30 minutes, the Time object will refer to 1970-01-01 00:30 UTC. But here comes the catch: timeDiff.toString() will output the time in the default time zone, that is, in most cases the time zone where you are currently are.
Long story short: Do not force an interval (duration, time difference) into a Time object. Either use a Duration class (Joda has one) or just do the division and modulo calculations yourself, as proposed by Kushan.
Looks like a duplicated question, have you seen already this answer?
How to find difference between two Joda-Time DateTimes in minutes
You should take a look at Joda time:
http://www.joda.org/joda-time/
Your problem is that when you create the time diff with
Time timeDiff = new Time(timeDiffLong);
and output that with System.out.println(timeDiff) then the result is shown for your local time zone. You can see that when you do this:
System.out.println(new Time(0));
TimeZone.setDefault(TimeZone.getTimeZone("PST"));
System.out.println(new Time(0));
That produces the following output here
00:00:00 //will probably be 20:00:00 for you
16:00:00
In short: Your time difference is shown as a GMT date converted to your local time zone and that is why its several hours off.
This code:
package test;
import java.util.Date;
public class DateUnderflow {
public static void main(String[] args) {
Long timestamp = -8120649749785140250L;
System.out.println(new Date(timestamp));
}
}
Produces the following output:
"Sat Aug 03 10:00:59 CET 257325894"
How come? An underflow without an exception?
Doc says says the date parameter of Date(long date) is the number of milliseconds since epoch, so I'm a bit surprised to find myself that far into the future..
My setup:
Linux mint 17.1
Eclipse Luna Service Release 1a (4.4.1)
java7-openjdk-amd64
RTFM (manual)
public Date(long date)
Constructs a Date object using the given
milliseconds time value. If the given milliseconds value contains time
information, the driver will set the time components to the time in
the default time zone (the time zone of the Java virtual machine
running the application) that corresponds to zero GMT.
Parameters:
date - milliseconds since January 1, 1970, 00:00:00 GMT not to exceed
the milliseconds representation for the year 8099. A negative number
indicates the number of milliseconds before January 1, 1970, 00:00:00
GMT.
not to exceed the milliseconds representation for the year 8099
In addition to this I am most likely saving someones time by saying: if you deal with time in java use joda time library:
http://www.joda.org/joda-time/
Max long value is 9223372036854775807. If you exceeds this max value, next value would be minimum max value.
If you construct a date out of this max long value, this will results to a date. What about a date next to that. If you add more mili-second to the next starts from minimum long value.
-8120649749785140250 is equivalent to 9223372036854775807 + 1102722287069635559
Try System.out.println(9223372036854775807L+1102722287069635559L);
I believe your code is equivalent to
Date d1 = new Date(9223372036854775807L); // Date for max long value
Date d2 = new Date(d1.getTime() + 1102722287069635559L); // plus some mili-seconds
System.out.println(d2);
This gives the result you are getting.
The date in database is 2012-03-20 12:24:34.123456. We need to display it in long format.so, we used getTime() method. But when we are converting back to date again, the nano seconds are not matching exact precision. The date after conversion is 2012-03-20 12:24:34.123. last 456 is missing. any one help to get exact date with nano seconds.
From javadoc
java.util.Date, getTime(), returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object. 456 is missing because is less than millisecond, is microseconds
You can use getTimestamp() instead of getTime(). The java.sql.Timestamp object returned, when treated like a java.util.Date, has integer seconds. By calling getNanos() on it, you can get the fractional seconds in nanoseconds.
I have a problem of inconsistency with time objects
Time time1 = new Time(72000000); //21:00
Time time2 = new Time(new Date().getTime()); //before 21 pm
time2.before(time1);
The last line returns always false, why?
Time:
A thin wrapper around the java.util.Date class that allows the JDBC API to identify this as an SQL TIME value. The Time class adds formatting and parsing operations to support the JDBC escape syntax for time values.
The date components should be set to the "zero epoch" value of January 1, 1970 and should not be accessed.
http://docs.oracle.com/javase/7/docs/api/java/sql/Time.html
Basically you're comparing 21:00 at the first of january 1970 to your current date at some point in the day. Obviously the former time happens earlier and is 'smaller'.
This is not doing what you think it's supposed to do!
Time time1 = new Time(72000000);
See this:
Time
public Time(long time)
Constructs a Time object using a milliseconds time value.
Parameters:
time - milliseconds since January 1, 1970, 00:00:00 GMT; a negative number is milliseconds before January 1, 1970, 00:00:00 GMT
Now, hopefully you understand...
Since you didn't specify otherwise, I assume that the Time object is java.sql.Time.
This object uses a superclass of java.util.Date so it is actually a full date object. For the purposes of JDBC (SQL) it only concerns itself with the time portion of the date.
This:
Time time1 = new Time(72000000);
...creates an object that represents 1-January-1970 21:00 hours. It will always be before any current time.
Seems that time1 is 14:00 . Run the below code snippet.
Time time1 = new Time(72000000); //21:00
System.out.println(time1); //prints 14:00
System.out.println(new Date());
Time time2 = new Time(new Date().getTime()); //before 21 pm
How does java.util.Date.getTime method convert a given date & time into long number?
Java API documents say that - "Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object."
Appreciate any help.
Check out the Date.java source code.
You'll see that in the simplest case, the Date object stores the number of milliseconds since 1970, rather than the date/time etc.
Actually, despite the apparently unambiguous definition in the Java API doc, it is interesting to note that the number of milliseconds reported is not the actual number of physical milliseconds, or seconds for that matter, that have elapsed since January 1st 1970 00:00:00 GMT. It is really the number of physical seconds plus the number of leap seconds that have been artificially inserted.