# Threaded and forked select with timeout is impacted by syste

**URL:** <https://www.ruby-forum.com/t/threaded-and-forked-select-with-timeout-is-impacted-by-syste/119376>\
**Category:** Ruby\
**Created:** [November 6, 2007, 3:23pm UTC](https://www.ruby-forum.com/t/threaded-and-forked-select-with-timeout-is-impacted-by-syste/119376 "2007-11-06T15:23:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rlwinter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/ecccb3/32.png) [@rlwinter](https://www.ruby-forum.com/u/rlwinter)\
**Post date:** [November 6, 2007, 3:23pm UTC](https://www.ruby-forum.com/t/threaded-and-forked-select-with-timeout-is-impacted-by-syste/119376/1 "2007-11-06T15:23:23Z")

</div>

I am using ruby 1.8.6 on Fedora Core 6 and 7

I have encountered a problem with the timeout for a select statement  
inside a thread or fork.

If the timeout is set for a duration of time and the system time is  
moved back one hour the duration is increased 1  
hour. If the time is moved forward 1 hour the duration is shortened one  
hour or fires instantly once the duration has  
been exceeded.

I tested this functionality in c and timeout duration is not impacted by  
a system time change.

For a simple test…

create a thread that loops 30 times  
sleep for 1 second (select with 1 second timeout)  
and put a string to the console

While the program is running set the system time back say 5 seconds  
you will see a 5 second gap between prints.

---

<div class="post-metadata">

**Author:** ![rlwinter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/ecccb3/32.png) [@rlwinter](https://www.ruby-forum.com/u/rlwinter)\
**Post date:** [November 6, 2007, 9:24pm UTC](https://www.ruby-forum.com/t/threaded-and-forked-select-with-timeout-is-impacted-by-syste/119376/2 "2007-11-06T21:24:21Z")

</div>

On Nov 6, 2007, at 9:25 AM, Robert W.iams wrote:

> If the timeout is set for a duration of time and the system time is  
> moved back one hour the duration is increased 1  
> hour. If the time is moved forward 1 hour the duration is  
> shortened one  
> hour or fires instantly once the duration has  
> been exceeded.

I’m not sure why the Ruby version fails and the C version works, but  
it is generally considered a really big mistake to alter a system clock  
in this way. Are you adjusting for daylight savings? The underlying  
clock should be in GMT and then daylight savings is simply handled by  
changing the way the GMT time is displayed. That is to say, the  
underlying clock doesn’t change at all for daylight savings.

If you really have to change the underlying system clock, I would do  
it in single user mode or at least after stopping any daemons or  
long running applications.

Gary W.