RE: [Quickfix-developers] UtcTimeStamp::tm_isdst = -1

[Brendan B. B. <br...@ka...>]

Hi Oren,

> It's because of how we are doing time comparisons in some places.  The 
> problem is when you need to do conversions to time_t using mktime.  If 
> you are in a time zone that is observing daylight savings, and you do a 
> mktime, if you convert back into a tm_struct you will be one hour off.  
> By setting this value to -1, the system will do the appropriate check 
> for the timezone when doing the conversion.  Why are we using time_t?  
> Mostly to make it easier to do time comparisons.  I don't think it is 
> really justifiable to keep doing this.  If we get rid of using time_t 
> and rewrite the UtcTimeStamp comparison operators to use the 
> constituents of the tm struct, we can probably stop doing this.

> On Aug 2, 2004, at 1:46 PM, Brendan B. Boerner wrote:
> 
> > UtcTimeStamp::setCurrent() sets tm_isdst = -1, why is this done
> > instead of using the value as set by gmtime()?
> >
> > Thanks,
> > Brendan

Between the Microsoft documentation :-) and lack of clarity regarding
localtime/utc conversion between functions (why isn't there a
mktime() which supports converting a utc tm_struct back to local
time? :-( ) I did some tests converting time_t to tm_struct using
localtime()/gmtime()/mktime().  My results are below is you're
interested.

Note that in the cases I checked '>saved_time_t' was usually either
=utc or utc +1h e.g.  localtime + utc_offset / localtime +
utc_offset+1h, etc.

    Saved_time_t: 8/3/04-05:11:12 (utc)
    Date Run: 8/3/04
    saved_time_t (localtime):
        -> ctime(): localtime
        -> gmtime() -> strftime(): utc
                    -> mktime(): >saved_time_t
                    -> mktime() -> ctime(): utc + 1h

    saved_time_t (localtime):
        -> ctime(): localtime
        -> localtime() -> strftime(): localtime
                    -> mktime(): =saved_time_t
                    -> mktime() -> ctime(): localtime

    saved_time_t (utc):
        -> ctime(): utc
        -> gmtime() -> strftime(): utc + 5h
                    -> mktime(): >saved_time_t
                    -> mktime() -> ctime(): utc + 6h

    saved_time_t (utc):
        -> ctime(): utc
        -> localtime() -> strftime(): utc
                    -> mktime(): =saved_time_t
                    -> mktime() -> ctime(): utc

    strptime2() -> struct tm:
        -> strftime(): utc
        -> mktime(): saved_time_t + 18K (5h) e.g. UTC
        -> mktime() -> ctime(): utc

    time(NULL):
        -> ctime(): localtime
        -> gmtime() -> strftime(): utc
                    -> mktime(): >time(NULL)
                    -> mktime() -> ctime(): utc + 1h

    time(NULL):
        -> ctime(): localtime
        -> localtime() -> strftime(): localtime
                    -> mktime(): =time(NULL)
                    -> mktime() -> ctime(): localtime


> Actually, thinking this through a little more, it probably has more to 
> do with adding and subtracting seconds to a UtcTimeStamp.  This is not 
> something I really know how to do reliably without using a time_t.  Any 
> suggestions on this?

From these results, I think you're ok on operator+=() as you're doing
a tm_struct(containing a utc time) into a time_t(utc) and then back
using localtime.  That should work.  In fact, it seems to be the only
thing which will :-).

void UtcTimeStamp::operator+=( long seconds )
{
  tm copy = *this;
  time_t time = mktime( const_cast < tm* > ( &copy ) );
  time += seconds;
  *static_cast < tm* > ( this ) = time_localtime( &time );
  tm_isdst = -1;
}

There's no operator-=() to worry about.  The long operator-( const
UtcTimeStamp&, const UtcTimeStamp& ) should be fine as well as the
diff will be between two time_t(utc).

Cheers,
Brendan