Re: Problems within epicsTime.cpp

[Kay-Uwe Kasemir <kasemirk@ornl.gov>]

Hi:

Yes, make it a constant.

Short story:
Originally that was just a constant as Peter suggested.
The current epicsTime initialization code is very interesting,
but doesn't give us any advantage.
On the contrary: We now have 2 examples for people loosing
a lot of time trying to debug it.

Longer detail about the other story:
A vxWorks specific problem with that section of
the epicsTime initialization code resulted in a similar 1-hour-off  
situation
for us in those weeks where the US used
a new pivotal date for the daylight saving time switch.
Some of the vxWorks back-and-forth routines from local to UTC
used tm_isdst, other didn't.
I think it was mktime which ignored the tm_isdst that you pass
in, instead using it's own idea about it, and that resulted
in a 1 hour error.
There's some tech-talk thread on this.
We hacked around that by NOT configuring the TIMEZONE
correctly until after iocInit:
When using EPICS_TIMEZONE, but leaving TIMEZONE blank,
the epicsTime initialization would do the back-and-forth
computations thinking it's running UTC,
and then TIMEZONE is set correctly to EPICS_TIMEZONE.

-Kay

On Jan 31, 2008, at 05:22 , Denison, PN (Peter) wrote:
> I'm not entirely clear why we're going through the
> whole rigmarole of calling mktime() twice, and calculating the
> difference, rather than hard-coding the value of 631152000. It's  
> not as
> if the difference between the two epochs can vary. I had initially
> thought that we could leave the existing code in place, and run
> epicsEnvSet to set the timezone to UTC, and then revert it, then I
> realised how unnecessary it is, since we are trying to get a constant
> out.
>
> Can I replace this code in epicsTimeLoadTimeInit with a constant?