[Java] java.util.Date geeft verkeerde tijd i.c.m. Windows

[Standeman]

Ik heb een beetje raar probleem op een server (Win2000 server) dat ik op mijn eigen werkstationnetje (Win2000 Pro) niet kan nabootsen. Het verhaal gaat als volgt:

Wanneer ik op mijn machine

code:

System.out.println(new java.util.Date());

uitvoer, krijg ik gewoon de datum en tijd te zien welke windows ook in mijn taskbar aangeeft. Echter, als ik het op mijn server doe, dan is het op eens 1 uur vroeger dan de systeem tijd aangeeft??

Op beide machines:
- is dezelfde tijd ingesteld
- is Windows Time Service gestopt
- is automatic daylight saving uitgeschakeld
- staat de timezone ingesteld op "GMT +01:00 Amsterdam"
- staat "Your locale" in "regional options" ingesteld op "dutch".

In google heb ik niets gevonden wat van toepassing is (het is ook vrij moeilijk om een goede query te bedenken) en helaas kan ik niet op het java.sun.com forum komen (ik vermoed dat het down is ofzo).

Iemand enig idee waar het aan kan liggen? Ik zou het namelijk graag op mijn eigen machine willen nabootsen.

[Verwijderd]

Zelfde versie van Java? Kan misschien zijn dat er in een van de twee een bugje zit?

[ronaldmathies]

druk eens je System.getProperties() af. En kijk of daar locale instellingen staan en waarop ze staan.

[Standeman]

Verwijderd schreef op dinsdag 05 april 2005 @ 12:02:
Zelfde versie van Java? Kan misschien zijn dat er in een van de twee een bugje zit?

Ja, de JVM komt overeen (1.4.2), dus dat kan het probleem niet zijn..


@RonaldMathies
Ik ga gelijk even kijken...


Ik heb even gekeken, en beide geven hetzelfde weer, zoals:
user.language=nl
user.timezone=GMT+01:00
os.version=5.0
os.name=Windows 2000
user.country=NL

de overige properties lijken me er niet toe te doen. Ik denk ook dat het gewoon ergens aan windows ligt.. maar zou alleen niet weten waarom of wat.


Het enige verschil is, is dat op de server java.vm.version=1.4.2_04-b05 staat en mijn ws java.vm.version=1.4.2_07-b05

[ Voor 45% gewijzigd door Standeman op 05-04-2005 13:20 ]

[vinnux]

Wij leven nu in GMT+02:00
Vandaar het ogenschijnlijke tijdsverschil.

Beide servers geven exact dezelfde tijd weer.
Het toepassen van nieuwe regional setting werkt alleen als je dit via b.v. PcAnywhere en daarna uitlogd.
Wanneer je het in een Terminal Service venster doet wordt het doorgevoerd. Heb ik ook mee lopen stoeien.

[ Voor 115% gewijzigd door vinnux op 05-04-2005 14:58 ]

[Standeman]

vgouw schreef op dinsdag 05 april 2005 @ 14:54:
Wij leven nu in GMT+02:00
Vandaar het ogenschijnlijke tijdsverschil.

Beide servers geven exact dezelfde tijd weer.
Het toepassen van nieuwe regional setting werkt alleen als je dit via b.v. PcAnywhere en daarna uitlogd.
Wanneer je het in een Terminal Service venster doet wordt het doorgevoerd. Heb ik ook mee lopen stoeien.

Mijn probleem is dat het op mijn workstation het wel goed gaat, maar op de server niet, met beide dezelfde instellingen (GMT+01:00). Ik wil graag weten waar het verschil vandaan komt..

Ik neem aan dat er qua tijd / datum er weinig verschil zit tussen w2k server en w2k pro

offtopic:
misschien deze topic laten verschuiven naar WOS ?

[ Voor 6% gewijzigd door Standeman op 05-04-2005 16:36 ]

[MrBucket]

Ik stond net op het punt om te zeggen dat TS anders maar eens de source van java.util.Date moest bekijken, misschien dat daar nog iets belangrijks uit afgeleid kon worden...

...maar nu zie ik dat je de sourcecode van de java SDK tegenwoordig apart moet downloaden, en moet registreren etc. Da's toch nog niet zo lang?

[FendtVario]

Als ik alle ontwikkelingen goed gevolgd heb released Sun pas sinds kort de (gedeeltelijke) broncode van Java. Sun is onder druk gezet om de code openbaar te maken volgens een OpenSource model maar Sun wil nog niet echt omdat ze bang zijn grip te verliesen op alle verschillende distributies die mogelijk ontstaan. Je kunt dus ook nog de gewone SDK ophalen zonder registratie.

[Onno]

MrBucket schreef op dinsdag 05 april 2005 @ 18:23:
...maar nu zie ik dat je de sourcecode van de java SDK tegenwoordig apart moet downloaden, en moet registreren etc. Da's toch nog niet zo lang?

De broncode van de standaard classes zit nog steeds gewoon bij de JDK, in src.zip. Waar je nu naar kijkt is de broncode van de JVM zelf. (die ook alweer geruime tijd op deze manier aangeboden wordt trouwens; het enige wat recent veranderd is is dat dat nu ook onder een andere licentie mogelijk is)

[ Voor 13% gewijzigd door Onno op 05-04-2005 19:23 ]

[Verwijderd]

Standeman schreef op dinsdag 05 april 2005 @ 11:58:
Wanneer ik op mijn machine

code:

System.out.println(new java.util.Date());

uitvoer, krijg ik gewoon de datum en tijd te zien welke windows ook in mijn taskbar aangeeft. Echter, als ik het op mijn server doe, dan is het op eens 1 uur vroeger dan de systeem tijd aangeeft??

Op beide machines:
- staat de timezone ingesteld op "GMT +01:00 Amsterdam"

Iemand enig idee waar het aan kan liggen? Ik zou het namelijk graag op mijn eigen machine willen nabootsen.

"the Date class is intended to reflect coordinated universal time (UTC)"
http://stein.cshl.org/jade/distrib/docs/java.util.Date.html

--
"Calendar's getInstance method returns a GregorianCalendar object whose time fields have been initialized with the current date and time:"

code:

Calendar rightNow = Calendar.getInstance();

http://stein.cshl.org/jad....util.Calendar.html#_top_

Lijkt me duidelijk.

Check eens op de server de volgende uitvoer:

code:

C:\>
C:\>NET TIME

[Standeman]

Het Calendar object heb ik nog niet gebruikt, maar dat is natuurlijk ook mogelijk. Echter wordt in de codebase wel op meer plaatsen java.util.Date gebruikt en ik zie er op het moment weinig in om overal eerst een Calendar object te maken en deze om te zetten in een Date object.

Het gene waar ik echt in ben geinteresseerd is _waarom_ ik op 1 windows machine Wed Apr 06 07:46:46 GMT+01:00 2005 terug krijg en op de andere Wed Apr 06 06:46:46 GMT+01:00 2005

Terwijl de machines zelf behoorlijk vergelijkbaar zijn en ze de dezelfde tijd / locale instellingen hebben..

[Standeman]

Ik heb even in het Date object gekeken en heb gezien dat wanneer een Date object wordt gecreeerd dat System.currentTimeMillis wordt aangeroepen en er verder weinig gebeurt. Dit beteknd dus dat System.currentTimeMillis een ander getal opleverd op machine A dan op machine B. Het probleem is nu verschoven, maar ik ben nog geen stap dichterbij over het waarom

Iemand nog ideeen?

Update:
Ik heb het net even uitgeprobeerd Het Calendar object geeft precies hetzelfde probleem, ook een uur vroeger dan windows zelf aangeeft in de taskbar.

[ Voor 19% gewijzigd door Standeman op 06-04-2005 09:35 ]

[RayNbow]

Standeman schreef op woensdag 06 april 2005 @ 08:57:
Ik heb even in het Date object gekeken en heb gezien dat wanneer een Date object wordt gecreeerd dat System.currentTimeMillis wordt aangeroepen en er verder weinig gebeurt. Dit beteknd dus dat System.currentTimeMillis een ander getal opleverd op machine A dan op machine B. Het probleem is nu verschoven, maar ik ben nog geen stap dichterbij over het waarom

Iemand nog ideeen?

Returns: the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC.

In andere woorden, als de datum/tijd niet klopt van je machine dan klopt de waarde van currentTimeMillis() ook niet. Tenzij natuurlijk de implementatie van de JVM bugged is...

[Standeman]

RayNbow schreef op woensdag 06 april 2005 @ 09:34:
[...]


[...]

In andere woorden, als de datum/tijd niet klopt van je machine dan klopt de waarde van currentTimeMillis() ook niet. Tenzij natuurlijk de implementatie van de JVM bugged is...

Tja.. lijkt me eigenlijk sterk dat het een JVM bug is. Ik neem aan dat het uur / dag wel vaker op deze planeet gebruikt wordt. Maar ik heb iig weer wat meer om bij google in te vullen.

[RayNbow]

Kijk ff of dit hetzelfde print op beide machines...

Java:

import java.util.Date;
import java.util.Calendar;
import java.util.TimeZone;

//...

Date datum = new Date();
Calendar nu = Calendar.getInstance();

// print als het goed is 1.0 2x af
System.out.println(nu.get(Calendar.ZONE_OFFSET) /3600f/1000);
System.out.println(nu.get(Calendar.DST_OFFSET) /3600f/1000);

// moet true printen
System.out.println(nu.getTimeZone().inDaylightTime(datum));

// dit print een hele regel vol met settings :P
System.out.println(nu.getTimeZone());

[Standeman]

RayNbow schreef op woensdag 06 april 2005 @ 10:08:
Kijk ff of dit hetzelfde print op beide machines...

Java:

import java.util.Date;
import java.util.Calendar;
import java.util.TimeZone;

//...

Date datum = new Date();
Calendar nu = Calendar.getInstance();

// print als het goed is 1.0 2x af
System.out.println(nu.get(Calendar.ZONE_OFFSET) /3600f/1000);
System.out.println(nu.get(Calendar.DST_OFFSET) /3600f/1000);

Doettie niet.. 1.0 en 0.0 wordt afgedrukt. Kan ook wel kloppen omdat DST in Windows uit staat.

Java:

// moet true printen
System.out.println(nu.getTimeZone().inDaylightTime(datum));

Print false, omdat DST uit staat.

Java:

// dit print een hele regel vol met settings :P
System.out.println(nu.getTimeZone());

Dat laatste geeft:
sun.util.calendar.ZoneInfo[
id="GMT+01:00",
offset=3600000,
dstSavings=0,
useDaylight=false,
transitions=0,
lastRule=null]
Tot zover niets wat ik niet verwacht had...


Verder heb ik nog weinig nieuws ontdekt. Mogelijk kan het nog wat te maken hebben met de BIOS datum o.i.d. en DST opties. (Iemand verstand van een IBM xSeries 335??). Maar als ik overdag de machine even boot, wordt ik hier ter plekke afgeschoten , dus ik kan waarschijnlijk pas vannacht gaan kijken.

[ Voor 3% gewijzigd door Standeman op 07-04-2005 10:38 ]