[fpc-devel] OS2 DOSCALLS and timezone

[Tomas Hajny]

On 7 Apr 14, at 12:47, waldo kitty wrote:


> i've a need to work with the OS2 timezone parameter in the OS' system clock... 

Which "parameter" do you mean, DosCalls.TDateTime (aka _DATETIME 
defined in OS/2 headers for C)?


> i'm not understanding a few things and haven't been able to figure out the code 
> path so i'm writing here to ask for some assistance... if this should be in the 
> user's list, please let me know and i'll move the conversation over there...

fpc-pascal would be indeed more appropriate, since fpc-devel is 
primarily about FPC development (rather than development using FPC).


> ok, so...
> 
> if i do not use the doscalls unit, the timezone parameter returns as 0 (zero) 
> instead of -1 when it is uninitialized... if i use the doscalls unit, i get -1 
> as desired... now the problem comes with how to set the timezone to the locale 
> the system is located in...

Well, yes - assuming that the underlying operating system (OS/2 / 
eCS) provides a clearly documented and well working solution to that 
task, right? ;-)


> i know that FPC on OS2 uses EMX for some/most/all of its accesses... rummaging 

No, it does not use EMX at the API level. FPC uses native OS/2 API 
(almost ;-) ) exclusively for target OS2 nowadays. The only two 
exceptions are API calls only provided by segmented 16-bit calls in 
OS/2 (basically only console API functions - low-level keyboard, 
video and mouse access) which are remapped to standard 32-bit mode 
calls by EMX library emxwrap.dll and then for direct I/O port access. 
This was different in 1.0.x series and it is different for target 
EMX, of course, but that is not fully working now so I don't think 
that you'd be using that one. EMX tools (especially the linker and 
debugger) are still necessary for development, but that is not 
relevant for your case.


> through the EMX code shows that it explicitly does not allow a write to the 
> timezone field... the EMX code also shows another field, dstflag, which appears 
> to be forced to 0 (zero) but i have not been able to access this field...
> 
> additional rummaging in the EMX code shows that the timezone field in time.h is 
> made of two ints, tz_minuteswest and tz_dsttime but again, i don't know how to 
> get to them...

You shouldn't need those.


> the thing about all of this is that work in the OS was left unfinished... there 

Indeed. Moreover it is not only unfinished, but not even designed 
fully (or at least the design was not documented properly). This led 
to situation when different people started their own design to fill 
that gap - obviously, the different designs were not compatible to 
each other. :-(


> is supposed to be an app (clock most likely) that handles setting the timezone 
> stuff when necessary and adjusting it when daylight saving switches on and 
> off... there was one (worldclock IIRC) that used to do this but it is no longer 
> included in eCS... peter moylan wrote a tool, TZSet, that checks and sets the OS 

I can't comment on what's included in later eCS version. My eCS 1.0 
provides automated time changes based on DST section of the timezone 
setting.


> clock's timezone field based on the TZ environment variable but this tool has to 
> be executed more often than just on boot... preferably daily as soon after 0200 
> (or whenever one's local DST changes) as possible...
> 
> my idea was to see about writing a small clock tool to handle this like the no 
> longer included clock tool did...
> 
> i'm not sure what needs to be done to gain access to the dstflag or the timezone 
> structs and am not really sure what they are supposed to contain... any 
> assistance in this would be helpful... i can get some source code in modula-2 
> which i understand is similar to pascal but then i'm still stuck with accessing 
> everything thru EMX or, some how, directly into the system which is likely a bit 
> more dangerous for my playing...

No, there is no difference. You need to use DosSetDateTime to shift 
the time by the DST offset. You can set ("initialize") the timezone 
field too (so that future calls to DosGetDateTime return it), but it 
probably does not change anything for most (likely all?) applications 
and it would not be preserved among system restarts.

As a starter, I'd suggest you to use unit "os2util" which I have 
created for Synapse some time ago and which should hopefully suit 
your needs. It depends on correct setting of the TZ variable. 
"Correct" implies full setting including the DST details as suggested 
e.g. by package time868f.zip found e.g. on Hobbes (os2util supports 
multiple TZ notations, the one expected by time868f.zip being one of 
them).

However - the easiest solution of your primary issue (not requiring 
any kind of programming whatsoever as long as your machine is 
connected to Internet) is probably using a "daytime" client (like the 
one provided in time868f.zip package ;-) ) which synchronizes your 
clock with a source in Internet automatically while properly 
observing the changing offset during DST switches. Hobbes provides 
multiple implementations of such a client.

Tomas