avoid repeated tzset() calls

[irfanHaslanded]

The tzset() function initializes the tzname variable from the
TZ environment variable.

There doesn't seem to be any valid usecase of calling this repeatedly.
It is an overhead that can be avoided.

[michalvasko]

Okay, just add the docs please.

[jktjkt]

Just remove that explicit call to tzset(). In both of these places where tzset() is invoked, the very next function that gets called is locatime_r which is documented to also perform the tzset()'s side effects.

[michalvasko]

From my man page:

       The  localtime() function converts the calendar time timep to broken-down time representation, expressed relative to the user's specified timezone.  The function also
       sets the external variables tzname, timezone, and daylight as if it called tzset(3).  The return value points to a statically allocated struct which  might  be  over‐
       written  by subsequent calls to any of the date and time functions.  The localtime_r() function does the same, but stores the data in a user-supplied struct.  It need
       not set tzname, timezone, and daylight.

Also, the tests started to fail.

[irfanHaslanded]

Just remove that explicit call to tzset(). In both of these places where tzset() is invoked, the very next function that gets called is locatime_r which is documented to also perform the tzset()'s side effects.

Unfortunately, this doesn't work.
It causes failure in

25: [ RUN      ] test_data_xml
25: [  ERROR   ] --- "2005-05-25T23:15:15.88888+00:00" != "2005-05-25T21:15:15.88888-02:00"
25:  1 FAILED TEST(S)
1/1 Test #25: utest_yang_types .................***Failed    0.04 sec

[jktjkt]

From my man page:
...

Oops, my bad.

[irfanHaslanded]

Yes, in the attached link as well

Unlike localtime(), the reentrant version is not required to set tzname
If the reentrant version does not set tzname, it shall not set daylight and shall not set timezone.

[michalvasko]

+1 for the function name.