Help save net neutrality! Learn more.
Close

Problem with daylight savings

Tanja
2012-04-27
2012-09-25
  • Tanja

    Tanja - 2012-04-27

    Hi,

    I am new to c++, so the following analysis is probably not the best.

    In our legacy application there seems to be a problem with daylight savings time since the conversion to owl Next. The commencement of daylight savings time is calculated incorrect => it should be february 25th 2012, but is calculated as march 1st. I think the problem is located in time.cpp - after modifiying the code (the bold parts) and recompiling owl Next - it is calculated correctly, nevertheless there still seems to be a problem determining the correct hour - as far as i know the phantom time is located between 2 and 3 o clock in the morning - but TTime seems to think it is between 1 and 2.

    If I try to initialize TTime with the time 25.3.2012 01:00 and afterwards print out the value with AsString then automatically one hour is added, trying to initialize it with 02:00 and then printing it out leads to a nonexistent Date of February 28, 2935093 1:00:00 am - which I could understand because it is within the phantom time, but the automatically added hour between 1 and 2 is still a puzzle.

    Additionally as far as I know even before 1986 daylight savings time in central europe started end of march and not end of april as the code below suggests. Is the problem probably located in the usage of the method AsString()

    Additionally

    TTime TTime::BeginDST( unsigned year )  
    {  
      if( year > 1986 ){  
        TDate endMarch(31, 3, year);  
        TDate &lastSunday = endMarch.Previous(SUNDAY)+7;  
        if(lastSunday.Month()==4) //**
          return BuildLocal( endMarch.Previous(SUNDAY), 2 );  
        else //**
          return BuildLocal( endMarch.Previous(SUNDAY)+7, 2 );  
      }  
    
      // Ah, remember those energy conscious years...???  
      if( year==1974 )  
        return BuildLocal( TDate(6,1,1974), 2 );  
      if( year==1975 )  
        return BuildLocal( TDate(23,2,1975), 2 );  
    
      TDate endApril( 30, 4, year );  
      return BuildLocal( endApril.Previous(SUNDAY), 2 );  
    }
    

    Regards, Tanja

     
    Last edit: Vidar Hasfjord 2012-09-27
  • Vidar Hasfjord

    Vidar Hasfjord - 2012-04-30

    Hi Tanja, thanks for reporting this issue. I have now registered this problem
    in our bug tracker. See issue #3522488, "TTime DST is calculated
    incorrectly".

    I don't know much about DST calculations, but a quick search on the net
    reveals that the rules for DST are complex and dependent on many factors
    (time-zone and historical rule-changes). See Daylight saving
    time
    at Wikipedia.

    I recommend having a look at Boost.DateTime. Personally, I have transitioned to Boost for
    auxiliary functionality like this, i.e. time, date, file, file/path names etc.

    In our legacy application there seems to be a problem with daylight savings
    time since the conversion to owl Next.

    I did a quick search in the revision log for "time.cpp" and these functions
    (BeginDST and EndDST) haven't been updated at least since 6.04. So I cannot
    pinpoint any OWLNext-specific changes to these functions.

    Is the problem probably located in the usage of the method AsString()

    Sorry, I don't understand. How is the problem related to AsString?

    Regards,
    Vidar Hasfjord

     
  • Ognian Tchernokojev

    Hi,

    I think one option for now could be to modify TTime to start using the
    timezone information from the operating system,
    methods like GetTimeZoneInformation() and
    GetTimeZoneInformationForYear() (Vista and later)

    In the future we can migrate to using Boost classes.

     
  • Vidar Hasfjord

    Vidar Hasfjord - 2012-05-02

    I think one option for now could be to modify TTime to start using the
    timezone information from the operating system

    Note that OWLNext currently has 3 time abstractions; TTime, TFileTime and
    TSystemTime. The latter two are thin wrapper-classes around the Windows API
    FILETIME and SYSTEMTIME structures, required for other components, such as
    TDateTimePicker, while TTime is a stand-alone auxiliary class, unrelated to
    the Windows API and not used anywhere else in OWLNext. (In my Owlet
    experimental branch I have removed it altogether, along with TDate.)

    Since the GetTimeZoneInformation function and friends deal with SYSTEMTIME, it
    is perhaps more proper to add this functionality to TSystemTime and leave
    TTime as is; unless OWLNext has introduced a bug since OWL 5. If so, it may be
    worth fixing.

    In any case, I recommend deprecating TTime and TDate.

     
  • Vidar Hasfjord

    Vidar Hasfjord - 2012-05-02

    By the way, I just did a file comparison with OWL 5 ("time.cpp", file date
    1997-03-25) and could not find any changes in TTime::BeginDST and EndDST,
    which means that this is not an issue introduced by OWLNext.

     


Anonymous

Cancel  Add attachments