The portable and consistent way to deal with this is to build a year-round TZ offset table (for each day in the current year in the current timezone) at application startup. Resolve each day's midnight local time to UTC (GMT), and record the effective timezone offset vis-a-vis UTC (GMT) for the day in question. Look for transitions in the effective TZ offsets year-round (transitions will indicate DST changes.) This approach is consistent and portable in that only depends on localtime
/gmtime
functioning reliably on the platform in question, and will return results fully consistent with localtime
/gmtime
calls. However, it becomes a bit more complicated if you require DST information for other timezones (than the process' default timezone.)
You can also directly use the TZ/Olson database (code available for both *nix and Windows), for maximum flexibility, but unless the underlying runtime/OS use the exact same timezone information (and your application uses TZ/Olson timezone information and gmtime
/localtime
interchangeably) then you're in for unpleasant surprises.