prevalence of "right" time zones without timegm()?

[Dave Daugherty]

Hi Tom,

I am one of the people who brought up this issue.  Our customer solved the problem by configuring for standard time zone, hence the urgency was greatly reduced to implement a code fix - so it got pushed to the back of the to-do list.

We support over 200 different variants of Unix with 1000's of installations and have only run across this problem once so far.

I am pretty sure the Centos version our customer was using already supports timegm.  I am having our OEM customer confirm this, and anyway it could be installed if necessary.  I have not tested timgem on any system to confirm that it includes the leap seconds if gmtime does.

Your proposed solution seems reasonable to me, but the man page for timegm suggests an alternative implementation using tzset and mktime.  I assume you considered that and discarded it?

       For a portable version of timegm(), set the TZ environment variable  to
       UTC, call mktime() and restore the value of TZ.  Something like

              #include <time.h>
              #include <stdlib.h>

              time_t my_timegm (struct tm *tm) {
                  time_t ret;
                  char *tz;

                  tz = getenv("TZ");
                  setenv("TZ", "", 1);
                  tzset();
                  ret = mktime(tm);
                  if (tz)
                      setenv("TZ", tz, 1);
                  else
                      unsetenv("TZ");
                  tzset();
                  return ret;
              }


Regards

Dave Daugherty
Centrify


> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of Tom Yu
> Sent: Tuesday, July 05, 2011 12:19 PM


> 
> Does anyone configure a "right" (leap-second-aware) time zone on a
> system that lacks timegm()?  (timegm() is the non-standard inverse
> function of gmtime().)  I'm trying to address the problem where
> conversion to formatted ASN.1 GeneralizedTime is sometimes
> non-invertible, causing failures that are difficult to debug.
> 
> I propose that we implement krb5int_gmt_mktime() using timegm() on
> systems that have it, using our existing custom implementation if
> timegm() doesn't exist.  This will improve the behavior of our code in
> a "right" time zone on a system with timegm(), but will preserve the
> existing broken behavior when parsing a formatted GeneralizedTime into
> a time_t value on a system that lacks timegm() and is configured with
> a "right" time zone.
> 
> My hypothesis is that it is very rare that a system is configured with
> a "right" time zone and also lacks timegm().  If you have evidence
> about this hypothesis, please let me know.
> 
> There are possible alternative solutions to this problem that also
> work on systems that lack timegm(), but they are more complicated or
> have other drawbacks.  To keep discussion focused, I prefer not to
> describe them in detail unless there is a strong opinion that my
> proposal is not viable.
> 
> Background information:
> 
>   The Olson time zone database can be compiled to include support for
>   leap seconds.  Some operating systems do so, producing an
>   alternative set of zone files known as the "right" zone files.  I
>   believe that most OSes do not configure a "right" time zone by
>   default.  (I would not recommend using the "right" zone files on
>   anything other than a completely isolated system.)
> 
>   In order for a system configured with a "right" zone to produce
>   correctly formatted times, the time_t values returned by the time()
>   function on that system need to include a count of all the leap
>   seconds that have occurred (24 seconds as of 2009), contrary to
>   POSIX, which effectively requires that every minute have exactly 60
>   seconds.  Obviously, this will cause many problems when exchanging
>   time data with POSIX-conforming systems, but one particular problem
>   affects the krb5 code.
> 
>   Our library uses gmtime() to format time_t values for encoding into
>   GeneralizedTime in ASN.1 messages.  An internal function,
>   krb5int_gmt_mktime(), converts formatted times into time_t values.
>   On a system where a "right" time zone is configured, these
>   conversions will not be inverses, because gmtime() will incorporate
>   accumulated leap seconds, and krb5int_gmt_mktime() will not.  This
>   results in mismatches in the small number of places where our
>   library makes exact time comparisons.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev