 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006UTC time in millisecond
Hi, How can I get UTC time in millisecond? I have used System.currentTimeMillis() but it isn't correct! Can you help me? thanks Palmis. > Hi, > How can I get UTC time in millisecond? > I have used System.currentTimeMillis() but it isn't correct! > Can you help me? > thanks > Palmis. In what way is it not correct? Don't forget that your OS is very unlikely to be able to provide time to millisecond accuracy. Common OS clock accuracy is of the order of 50-100ms. Some OS provide very accurate timing, but not those typically available on the desktop or server. It's normally the preserve of RTOS, where timing is critical.  SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 > Hi, > How can I get UTC time in millisecond? > I have used System.currentTimeMillis() but it isn't correct! > Can you help me? > thanks > Palmis. If system.currentTimeMillis() is returning the wrong time then there is probably something wrong with your operating system installation. Is it wrong by just a few hours? The difference between local and UTC time? I have seen this on some Windows installations. You may be able to fix it with some time settings in the Windows Control Panel. Steve Excuse me, I don't know very well differences between utc time and system time. Can you explain me, please? Thanks. Palmis > Excuse me, > I don't know very well differences between utc time and system time. > Can you explain me, please? > Thanks. > Palmis UTC is (more or less) the same as GMT, meaning it is the time at the Greenwich Meridian, which is in England. If you're for example in Europe, your local time will be 1-2 hours (depending on summer or winter time) different from UTC. Your system time is just the time to which your computer's hardware clock is set. This could be anything, it could even me completely wrong. Usually however, it is set to either your local time, or UTC. Normally, the operating system compensates the hardware clock setting, so that it (the OS) always shows your local time. System.currentTimeMillis() is indeed what you need. It may help if you explain why you think it is wrong, and what you need it for. SignatureBeware the False Authority Syndrome I quite agree with you. But if you want to persist this UTC time, for example in database, you need to convert it to something more readable than 1136916802187 (of course if you want some interoperability; if you don't - you can store it as INTEGER or BIGINT etc.). So I use java.util.Date. But it adjusts time by your time zone and DST. And DBMS will store current time as adjusted one, without any info about time zone. So in this case you need to compensate all these adjustments. > UTC is (more or less) the same as GMT, meaning it is the time at the > Greenwich Meridian, which is in England. If you're for example in > Europe, your local time will be 1-2 hours (depending on summer or winter > time) different from UTC. Point of pedantry: The Greenwich Meridian runs between the North and South pole, via some bushes near the Greenwich Observatory, UK. (I used to cross the meridian up to eight times a day on my way to and from work.) There are different time zones in Europe. You seem to be thinking of CET. WET (0-1 hours different from UTC) is used in England, for example. > Your system time is just the time to which your computer's hardware clock > is set. This could be anything, it could even me completely wrong. > Usually however, it is set to either your local time, or UTC. For performance reasons, the "hardware clock" and system clock will usually run independently and occasionally synced. A machine might not have a hardware clock at all. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Thomas Hawtin <usenet@tackline.plus.com> wrote in news:43c3fff6$0$1489 $ed2619ec@ptn-nntp-reader01.plus.net: > There are different time zones in Europe. You seem to be thinking of > CET. WET (0-1 hours different from UTC) is used in England, for example. Yes I was talking about CET. I'm not counting the UK as a European country, for historical and political reasons which are too off topic to discuss here. But of course there are Eastern European countries that use Moscou time. SignatureBeware the False Authority Syndrome > Thomas Hawtin <usenet@tackline.plus.com> wrote in news:43c3fff6$0$1489 > $ed2619ec@ptn-nntp-reader01.plus.net: [quoted text clipped - 6 lines] > discuss here. But of course there are Eastern European countries that use > Moscou time. Portugal currently uses the same time zone as the UK and I would count it as a European country. They did use CET for a while. > Portugal currently uses the same time zone as the UK and I would count > it as a European country. They did use CET for a while. I didn't know that, tx SignatureBeware the False Authority Syndrome On Tue, 10 Jan 2006 18:57:59 +0000, Thomas Hawtin <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone who said : >For performance reasons, the "hardware clock" and system clock will >usually run independently and occasionally synced. A machine might not >have a hardware clock at all. A PC has two clocks, a hardware clock and a timer interval tick that just counts ticks since last boot. A tick is 54.924 ms, about 18 a second, pretty low res. The timer ticks are less accurate and are synched to the hardware clock any time you set it. The original XT did not have a hardware clock, just the interval timer chip, so had to be told the time on each boot, and perhaps once a day to adjust it. 3rd parties invented dozens of clock cards for the XT. I collected the software for them to bail people out. The clock would get out of whack if software turned off interrupts too long and dropped a tick. The modern Pentiums have a third clock, a high resolution timer as well basically a cycle counter. I have written a Java class to access it. See http://mindprod.com/products1.html#PENTIUM You can keep your clock with subsecond accurary by resynching with an atomic clock each day. One way to do that is to run the JAWS app, setclock. See http://mindprod.com/webstarts/setclock.html Source is provided. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > A PC has two clocks, a hardware clock and a timer interval tick that > just counts ticks since last boot. A tick is 54.924 ms, about 18 a > second, pretty low res. The timer ticks are less accurate and are > synched to the hardware clock any time you set it. The tick interval depends on the operating system. About 54ms is correct for Windows 9X, but for Windows NT derivatives the period is usually 10ms (single processors) or 15.625ms (multi processors). Mark Thornton On Tue, 10 Jan 2006 21:59:08 GMT, Mark Thornton <mark.p.thornton@ntl-spam-world.com> wrote, quoted or indirectly quoted someone who said : >The tick interval depends on the operating system. About 54ms is correct >for Windows 9X, but for Windows NT derivatives the period is usually >10ms (single processors) or 15.625ms (multi processors). I wonder if the DOS emulator box still uses 54. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Hi, > How can I get UTC time in millisecond? > I have used System.currentTimeMillis() but it isn't correct! > Can you help me? > thanks > Palmis. if your time zone is different from "GMT+0", the value returned by System.currentTimeMillis() is not an UTC time, it is a local time. To obtain the UTC time you must convert the time returned by currentTimeMillis() like in the code below : long lCurrentTime; GregorianCalendar lGmtCalendar; long lUTCtime; lGmtCalendar = new GregorianCalendar(new SimpleTimeZone(0,"GMT+0")); gmtCalendar.setTimeInMillis(System.currentTimeMillis()); lUTCtime = lGmtCalendar.getTimeInMillis(); > if your time zone is different from "GMT+0", the value returned by > System.currentTimeMillis() is not an UTC time, it is a local time. That statement is plain and simply wrong. Unless you misconfigured your system clock. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ So what is the better solution? > So what is the better solution? I use the following code: Calendar cal = Calendar.getInstance(); cal.add( Calendar.MILLISECOND, -cal.get(Calendar.DST_OFFSET) - cal.get(Calendar.ZONE_OFFSET)); long lUTCtime = cal.getTime(); It takes into account summer/winter time transition. Hi Roman, I have modify your code: > long lUTCtime = cal.getTime(); with long lUTCtime = cal.getTime().getTime(); Because it is impossible to cast date to long. It's correct? palmis >>So what is the better solution? > [quoted text clipped - 6 lines] > long lUTCtime = cal.getTime(); > It takes into account summer/winter time transition. Hi Roman, Why do you think this is an improvement over System.currentTimeMillis()? On what system is this not the result not the same as new Date()? I'm really interested to know! -Paul >I use the following code: > Calendar cal = Calendar.getInstance(); [quoted text clipped - 4 lines] > long lUTCtime = cal.getTime(); >It takes into account summer/winter time transition. no it doesn't . The long you get out the end it still is plain old vanilla UTC. All the Timezone and DST stuff gets thrown away. you are right back with nothing different from System.timeInMillis, just some wasted objects. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > So what is the better solution? What is the problem? All we have is that System.currentTimeMillis() is "wrong". Is it an hour early? Three years late? A thousand years early? Does it give random numbers? Steve Thomas Weidenfeller <nobody@ericsson.invalid> wrote in news:dq0lgs$oq5$1 @news.al.sw.ericsson.se: >> if your time zone is different from "GMT+0", the value returned by >> System.currentTimeMillis() is not an UTC time, it is a local time. [quoted text clipped - 3 lines] > > /Thomas not exactly misconfigure, it's just a choice you make on setup. SignatureBeware the False Authority Syndrome > not exactly misconfigure, it's just a choice you make on setup. No, if System.currentTimeMillis() returns anything else then UTC you have a broken system. Wether you broke it deliberately, or accidentally doesn't matter. It is broken. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ >How can I get UTC time in millisecond? >I have used System.currentTimeMillis() but it isn't correct! see http://mindprod.com/webstarts/setclock.html Then it should be correct after that. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Ignoring the OS level inconsistencies mentioned in a later post, it's simply: Calendar.getInstance(TimeZone.getTimeZone("UTC")).getTime().getTime() -bhm Hi bhm, Do you intend to ignoring the solution of Roman with your solution? It's correct? Palmis. > Hi bhm, > Do you intend to ignoring the solution of Roman with your solution? > It's correct? NO it is NOT. DateFormat dfUTC = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss.s ZZZ zzz"); dfUTC.setTimeZone(TimeZone.getTimeZone("UTC")); DateFormat dfLocal = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss.s ZZZ zzz"); Date date1 = new Date(); Calendar cal = Calendar.getInstance(); System.out.println("Short way: " + dfUTC.format(date1)); cal.setTime(date1); cal.add(Calendar.MILLISECOND, -cal.get(Calendar.DST_OFFSET) - cal.get(Calendar.ZONE_OFFSET)); Date date2 = cal.getTime(); System.out.println("Long way: " + dfLocal.format(date2)); System.out.println(date1.getTime()); System.out.println(date2.getTime()); Results in setting the hours/min/secs the same but NOT the millisecond time! Long way: 2006-01-19 04:53:12.12 -0800 PST Short way: 2006-01-19 04:53:12.12 +0000 UTC 1137647240359 1137676040359 -Paul Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.