]> git.mxchange.org Git - simgear.git/commit
For the first time (no pun intended) in almost ten years time (again no
authordurk <durk>
Tue, 27 Jan 2009 22:43:13 +0000 (22:43 +0000)
committerTim Moore <timoore@redhat.com>
Wed, 28 Jan 2009 06:46:55 +0000 (07:46 +0100)
commite3fc89890c8f5cb4c09f936209e46878d2f2ea67
treebf9705bdf8bb9a402bffd2a67dc15ca9c531b277
parentce2a6cfe5c640e9c12a974a0ce4b2d12a19c672e
 For the first time (no pun intended) in almost ten years time (again no
 pun intended) that I'm touching the time library.

 Brian Schack reported that the traffic scheduler messes up the timestamps
 of the atlas network output. As it turns out, the c library functions
 asctime, and gmtime use a static copy of the tm struct to do the internal
 formatting. Our linux port of the SGTime class, incidentally, also stored
 it's master time stamp in this very same struct. Thus, formatting an
 arbitrary time value, would have the unwanted side effect of time travel.
 Usually, this would go unnoticed, because the actual time parameters would
 be updated before any damage could be done. But unwanted side effects, as
 in Brian's example could occur.

 On the MSVC port this appears to not have been a problem. Since that port
 used a copy of the tm struct to store it's master time stamps. Since the
 MSVC code also compiles cleanly on linux, it seems to be the way to go to
 use that approach. In addition, it also removes some conditional compile
 directives.

 I've only run a short test, but didn't see any undesirable side effects.
simgear/timing/sg_time.cxx
simgear/timing/sg_time.hxx