timezone

[Silvan Scherrer]

in zerotoaster the timestamps in the logfile should be in local time. right now it seems they are in GMT

[Silvan Scherrer]

the logentry is created like the following (according the developer):

if in zt_mta.ini the "timezone" is set, it takes the presets of the runtime.
i have timezone=ECT in zt_mta.ini

Date datBuffer = new Date();
SimpleDateFormat sdf = new SimpleDateFormat();
String strDateFormat = "dd.MM.yyyy"
String strTimeFormat = "HH:mm:ss"
long lngTime = System.currentTimeMillis();
//
StringBuffer strb = new StringBuffer();
datBuffer.setTime(lngTime);
sdf.applyPattern(strDateFormat);
strb.append(sdf.format(datBuffer));
strb.append(" ");
sdf.applyPattern(strTimeFormat);
strb.append(sdf.format(datBuffer));
String strMS = Long.toString(lngTime);
strb.append(".");
strb.append(strMS.substring(strMS.length() - 3));
strb.append(" ");
[...]
String strLog = strb.toString();

[Silvan Scherrer]

SimpleTimeZone.setDefault(TimeZone.getTimeZone("ECT"));

the above code has to be added at the top of the code snippet

[dmik]

What I see here is that the timezone setting only influences the ZT-HTTP module's timestamps in the log file. Others seem to always use the local time for timestamps.

[Silvan Scherrer]

timezones in zt are now ok, if in the ini timezone=xxx (in my case ECT) is set.
the developer provided a fixed jar.
what still looks strange is that java thinks i'm in GMT timezone. this is seen with SysProp: user.timezone=GMT

[dmik]

I found out the reason (expectedly): we miss various important Win32 registry keys, in particular:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
System\CurrentControlSet\Control\TimeZoneInformation

If I copy them from the INNOWIN registry key, all works. Seems that the InnoRT installer creates these keys. So it's an Odin problem again.

I don't like this approach because it's not clear how it gets updated when you change your TZ setting in OS/2.

I will try to derive TZ information from the TZ environment directly.

[dmik]

It's all complex. The thing is that not only Java has problems with the timezone when the corresponding entries are missing, but Odin itself as well: it thinks it's in GMT which means that it treats local time as GMT which in turn means that even if you set the correct timezone for Java with -Duser.timezone, it still gives you incorrect results.

There are two ways to fix it:

1. Provide the needed registry entries (Innotek way).
2. Construct these entries (except the "Time Zones" key which is kind of a static database and still needs to be provided by the installer) using the information from the TZ environment variable.

1. is weak because if you change your system TZ (via the Clock Synchronization setting for example, or manually in config.sys) it won't pick this change up. I don't know how their installer detects the initial Windows timezone but it surely doesn't do that at each startup.

So, 2. is basically enhancing 1. so that Odin will correct the corresponding keys at each application startup (KERNEL32.DLL load, actually). This requires a day of work at least because I need to hack the format used by Windows to describe the timezone rules (GMT offset, switching to DST, etc.) in the "Time Zones" key and provide an algorithm that will parse the TZ environment variable, match it with one of the Windows timezones and set it as the current one. I will also need to enhance the Odin installer to create the "Time Zones" key and test all the stuff.

[dmik]

Created ​http://svn.netlabs.org/odin32/ticket/20 on the Odin side.

[Silvan Scherrer]

i see, but i guess it's worth the effort. this gives us more fexibility

[dmik]

Odin32 has been fixed, the problem is gone.