Experimental Physics and
Industrial Control System

Not too fast:

epicsTimeToGMTM

converts timestamp to UTC broken-down time. tm_isdst is already zero since UTC has no DST.

Next:

epicsTimeFromTM()

converts a broken-down time back to a timestamp. It needs timezone information
to know how to do the conversion (uses 'mktime' internally). The conversion depends
on the timezone and DST where the broken-down time is interpreted.

Note that epicsTimeToStrftime again converts the timestamp to broken-down
format internally; this time using 'localtime' - which also uses timezone information.

You want the epicsTimeFromTM() and epicsTimeToStrftime from- and (implicit) to-TM
conversions to cancel so that you display your UTC.

What went wrong?  epicsTimeToGMTM() returns a tm with 'tm_dst==0'.
This is what you feed to epicsTimeFromTM(). However, the implicit localtime()
operation uses the DST setting of the current timezone, which right now
is probably 1.

In order to make this work you should set it to a negative value

epicsTimeToGMTM(&tm, &nsec, &timestamp);
tm.tm_isdst = -1; /* determine value from current timezone and timestamp */
epicsTimeFromTM(&utc, &tm, 0);
/* Note that the 'utc' timestamp is not truly representing the time 'tm' in UTC
   but 'tm' interpreted as the local time. It is only the subsequent, implicit
   conversion of the timestamp back to a 'tm' (again in the local timezone)
   which renders a representation of UTC again in the guts of
   epicsTimeToStrftime() -- ugly */


I recommend testing with various settings of the "TZ" environment variable
to make sure you got it right.

Lesson learned:
  epicsTimeFromTM() and epicsTimeToStrftime() both convert using
  the local timezone.

HTH
- Till


On 04/16/2013 03:02 PM, Eric Norum wrote: