Opened 10 years ago

Closed 10 years ago

#27 closed defect (fixed)


Reported by: Silvan Scherrer Owned by:
Priority: major Milestone: Beta
Component: general Version:
Severity: Keywords:


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

Change History (9)

comment:1 Changed 10 years ago by 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();
strb.append(" ");
String strMS = Long.toString(lngTime);
strb.append(strMS.substring(strMS.length() - 3));
strb.append(" ");
String strLog = strb.toString();

comment:2 Changed 10 years ago by Silvan Scherrer


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

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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

comment:5 Changed 10 years ago by dmik

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

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones

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.

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by dmik

Created on the Odin side.

comment:8 Changed 10 years ago by Silvan Scherrer

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

comment:9 Changed 10 years ago by dmik

Resolution: fixed
Status: newclosed

Odin32 has been fixed, the problem is gone.

Note: See TracTickets for help on using tickets.