OS4.1's Newlib & timezone.library

Does newlib is taking timezone.library into account when dealing with time, timezone and DST ? I ask because it does not seems to me, but I may have done something wrong...

@abalaban

I doubt this. newlib.library is a kickstart module while timezone.library is a "normal" disk based library. Hence newlib.library exists from the absolute beginning of the system boot process, while timezone.library will be loaded aeons (in terms of computer time scale) later.

timezone.library might come into play if it patches newlib.library, but again, I doubt this.

@tboeckel

What I'm trying to know is if newlib's time and timezone functions (time(), , localtime(), gmttime(), strftime() etc.) are aware/make use of timezone.library or not. My current problem is that I have my OS 4.1 system setup as using Paris timezone, i.e. UTC+1, or CET, but we are in summer and DST is currently in effect which take us to UTC+2 or CEST. Now using newlib functions it seems like I'm still at CET which give me crong results.

I'm aware newlib is a kickstart module while timezone.library is not but nothing tells me that, like some Exec functions with Locale.library, newlib implementation does not make use of timezone.library once loaded...
And if it's not the case I'm afraid then that we have some serious bugs in every ported softs that are computing times using newlib's functions.

@abalaban
A Hex search in newlib.library shows "timezone.library" there, which indicates that newlib might use that library. Have you compared the results of the C time functions in newlib to the same functions in you compile with clib2 instead?

@abalaban

Oh, it seems newlib.library indeed does use timezone.library:

52.12 (21.1.2007)
- Fixed a bug in opening timezone.library, it could get expunged and
newlib.library crashed calling ITimezone functions.

52.11 (19.1.2007)
- Added a workaround for the timezone.library problem.

52.10 (18.1.2007)
- More changes in the math functions, added gamma(), gammaf(), lgamma()
and lgammaf().
- Time functions now use timezone.library to get the UTC offset?and
dst flag.

If that doesn't work properly you better contact J?rg Stohmayer.

@abalaban

#REXX:DepsTrack.rexx sys:Kickstart/newlib.library.kmod
depstrack V0.3B por megacz@usa.com - tracks dependencies in binaries

/// analyzing 'sys:Kickstart/newlib.library.kmod' (517856 bytes)...
/// showing dependencies...
=== newlib.library
=== dos.library
=== elf.library
=== timezone.library
=== locale.library
=== bsdsocket.library
=== usergroup.library
=== timer.device
/// found 8 dependencies in 0.86 secs.


So it seems newlib uses timezone.

@tboeckel

Okay I made some experiment, consider the following sample
now this output

Now I'm not an expert of ANSI locale and timezone but in this small sample there things that annoy me :
1) strftime on the localtime give a timezone (%Z) of CET while we are currently at CEST and the offset (%z) and tm_gmtoff are correctly set to 2 hours
2) despite I used %A and %B to get locale's name for weekday and month I got english one no matter if I use setlocale() or not and whatever value I put for it (looking at the specs on opengroup.org it passing an empty string should have used the default system's locale)
3) strange (but opengroup.org says the result is undefined) strftime returns the correct timezone (CEST) when passed an UTC time...

@abalaban
I tried to compile your example with clib2 but it fails because the members
tm_gmtoff & tm_zone are not defined as part of the tm structure. The GNU WEB site lists those members as extensions. If you google tm_gmtoff, you will see lots of complaints from programmers having problems compiling programs referencing those extensions. Maybe the latest C compiler standards include those members but I wouldn't know where to find that out.
The definitions I found for those members seem to leave the definition of tm_zone for localtime open to interpretation. Maybe the newlib programmers interpret it to mean "the name of the timezone" and not the "UTC timezone designation for the timezone when daylight savings is in effect". One could argue that your problem might be a matter of interpretation rather than a bug.

@xenic

yes but then it's an interpretation that is not compliant with other systems having those extensions. In fact I discovered the problem while running a testcase of wxWidgets (which I'm porting to AOS4) and this part of the code is used on any other platform supported by wxWidgets (Windows, Linux, MacOS to name the major)