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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
