A quick inquire to tell when rollover happens:

{SmallInteger maxVal // (24*3600*1000) -> 'days'.
SmallInteger maxVal \\ (24*3600*1000) // (3600*1000) -> 'hours'.
SmallInteger maxVal \\ (3600*1000) // (60*1000) -> 'minutes'.
SmallInteger maxVal \\ (60*1000) // (1000) -> 'seconds'.
SmallInteger maxVal \\ (1000) -> 'milliseconds'.}.
	 {12->'days' . 10->'hours' . 15->'minutes' . 41->'seconds' .
823->'milliseconds'}

In a Pharo image, I see 112 senders of #millisecondClockValue and only
5 of #millisecondsSince:
That let room for future rollover-proof improvments...

First on the list, there are some senders of #deadlineSecs: in HTTPSocket.

Nicolas

2009/4/28 Andreas Raab <andreas.raab at gmx.de>:
> Hi -
>
> I'm not sure anyone cares about this (most likely Seaside users), but class
> Socket has some issues with clock-rollover which can be seen on high load
> servers that have enough uptime and load.
>
> The problem is caused by Socket>>deadlineSecs: which at the time of the
> clock rollover computes a deadline that can never be reached. If you've seen
> connections that wouldn't time out apparently at random there is a chance
> you have been affected by this type of issue.
>
> Bug (and fix) are posted at http://bugs.squeak.org/view.php?id=7343
>
> Cheers,
>  - Andreas
>
>