When world.timeofday falls into negatives, one hour's skew is added to any timestamp result. I tested it in 440 (since the Linux version we're running won't support a 442 compile yet) and Tiberath tested it in 442. I lose an extra hour using the stamp_timeofday verb below, and Tiberath gains one.
It's important to note that this only happens when the "after" item described in the output falls into negatives using the stamp_timeofday() verb, but not otherwise.
Numbered Steps to Reproduce Problem:
1.) Compile and run below code.
2.) Set offset to a negative integer that, when multiplied by 36000, will cause a negative result when subtracted from timeofday (when I discovered the bug at 10 PM central, I used -5).
c.) Use stamp_realtime() verb. Note correct output.
4.) Use stamp_timeofday() verb. Note one hour's skew.
Code Snippet (if applicable) to Reproduce Problem:
proc
_delimiter(s)
for(var/i=1;i<=length(s);i++)
var/t = text2ascii(s,i)
if(t == 47 || t < 45 || t > 57) return i
return 0
_duration2tick(t)
. = 0
if(isnum(t)) . = (t*36000)
else if(istext(t))
var/c = _delimiter(t)
if(c)
var
h = round(text2num(copytext(t,1,c)))
m = round(text2num(copytext(t,c+1)))
. = ((h*36000)+(m*600))
else . = (text2num(t)*36000)
timestamp(offset,stamp)
offset = _duration2tick(offset)
world << "timestamp() -- offset: [offset]"
var/timey = stamp
stamp += offset
world << "timestamp() -- before: [num2text(timey,15)]/after: [num2text(stamp,15)]/diff: [stamp-timey]"
world << time2text(stamp,"hh:mm.ss")
mob
var/t_offset = ""
verb
set_offset(t as text)
set desc = "hh:mm text or hh integer; positive and negative are valid"
src.t_offset = t
stamp_realtime()
world << "stamp_realtime():"
world << timestamp(src.t_offset,world.realtime)
stamp_timeofday()
world << "stamp_timeofday():"
world << timestamp(src.t_offset,world.timeofday)
Expected Results:
A timestamp src.t_offset hours in the past.
Actual Results:
Output from above code (using -7 as a t_offset at 12:16 AM central):
stamp_realtime():
timestamp() -- offset: -252000
timestamp() -- before: 2983581696/after: 2983329792/diff: -251904
17:16.32
stamp_timeofday():
timestamp() -- offset: -252000
timestamp() -- before: 189876/after: -62124/diff: -252000
16:16.28
Does the problem occur:
Every time? Or how often? Every time.
In other games? Not known.
In other user accounts? Not tested.
On other computers? Not owned.
When does the problem NOT occur?
It doesn't not occur to those who have tested it thus far.
Workarounds:
Using world.realtime works with the expected 20-30 second skew, but it's not really desirable for use in chat timestamps.
I get some different results when thrown into negative units.