Firstly i think this only happens if module date_timezone is activated. This module sets the variable "date_default_timezone" correctly depending on the adjusted timezone. So it sets in my case the date_default_timezone to +1 in the winter and +2 in the summer (Daylight-saving time - DST)
Now to my unlikely test case, maybe a similar problem is somewhere else in storm.
For me the switching to DST happend this year on Sunday 3/27.
I have created a timetracking from 13:00 till 14:00 on the 3/24 [1.]. I created this on this date.
After the 3/27 (after the switch to DST) i add some more timetrackings for the 3/24.
I created the following timetrackings:
3/23 23:00 - 23:59 [2.]
3/24 0:01 - 1:00 [3.]
3/24 12:00 - 13:00 [4.]
All works perfectly till here. In the list both of my timetrackings shows up correctly.
But now i switched my system time forward to the 12/1/2011. I'm back to normal time and now there is a strange effect.
When I filter the storm list for only the 3/24, only [1.] and [4.] shows up. [3.] disappeared and the [4.] now shows as date in the list the 3/24 11:00 (not 12:00).
If I filter the timetracking list for 3/23 till 3/24,  and  also have false dates (3/23 22:00 and 3/23 23:01). So all timetrackings i created in DST for the time before DST are one hour wrong.
Okay lots of brainfuck, hopefully someone understand me...
The function _timestamp_to_gm in strom.module subtract the date_default_timezone. In my case it is 7200 (+2hours), but the timestamp is in the past, where the default_timezone should only be 3600 (+1hours). So if the current time is in DST and the given timestamp not, this offset should be subtracted by 3600.
What wonder me also is, why in all gmtimestamp functions this subtraction happens. All this function uses the gmdate or gmmktime functions, so the returned value should be in a gmtimestamp, so why subtract the timezone offset once again?