UTC time in millisecond

[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.

 

[Nigel Wade]

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.

 

[Steve Horsley]

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

 

[S.B]

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();

 

[palmis]

Excuse me,
I don't know very well differences between utc time and system time.
Can you explain me, please?
Thanks.
Palmis

 

[Thomas Weidenfeller]

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

 

[palmis]

So what is the better solution?

 

[zero]

That statement is plain and simply wrong. Unless you misconfigured your
system clock.

/Thomas

not exactly misconfigure, it's just a choice you make on setup.

 

[zero]

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.

 

[Roman Gusev]

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.

 

[Roedy Green]

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.

 

[Roman Gusev]

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.

 

[Thomas Hawtin]

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

 

[Steve Horsley]

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

 

[zero]

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.

 

[Mark Thornton]

[email protected]:




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.

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.

 

[zero]

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

 

[Roedy Green]

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.

 

[Mark Thornton]

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

 

[Roedy Green]

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.