Timestamps and Related Bugs

By: Brian Green Date: May 27, 2006

Purpose:

This document details an old bug in the system dealing with timestamps and variable overflows.

Basics

The server provides timestamps to the scripting system which uses it for various aspects of the game. Unfortunately, due to Blakod's limitation on maximum integer size, this causes overflows on a regular basis and causes problems with the game.

Details

Getting a timestamp

The scripting system can get a timestamp from the server by calling the function GetTime(). Originally, this returned the normal system time, which is the number of seconds since 1970. Unfortunately, due to the limitations on the maximum integer value able to be stored by Blakod, the value of the timestamp is too large to store in a script variable.

The solution

The temporary solution has been to adjust the values returned by the function to the script system. This is accomplished in the file \blakston\blakserv\ccode.c on line 2045. Currently we subtract the long integer value of 1148678128L, which puts timestamp 0 sometime in the month of May, 2006. This fix will work until the new timestamp value overflows the maximum integer value, which will happen in approximiately 4 years and 3 months.

Likewise, the client has to recalculate timestamps passed to it. Currently this only affecs globe posts and mail message timestamps. This value is set in file \blakston\module\mailnews\newsread.c on line 372. The value should match the one set in the server above. This code goes into the mailnews.dll client file.

Systems affected by the bug

Currently, there are a few systems that use timestamps and that will be affected by this bug. They include:

Globe spam timer: users will be unable to post on the globes.
Suicide timer: users will be unable to suicide characters.
Mule casting timer: unguilded innocents cannot cast on others.
Globe post and new mail message timestamps will show an incorrect date.

The following systems are also affected, but can be fixed by doing "send class user UpdateTimeValues" at the server console or admin window.

Double death check in player: will prevent users from properly dying.
Guild rejoin time: will preventing users from rejoining a guild.

Adjusting the values above should fix all problems except for the timestamps on globe posts and mail messages. Unfortunately, these will always have incorrect dates when the times are adjusted.

Note that existing mail messages on the client have their timestamps converted into dates when they are downloaded.

Future directions

Unfortunately, it is easy to forget that we currently have a temporary fix. This means the bug will become active again and require the change of the variables mentioned above. It would be nice to have a solution that does not require recompiling the server and a client DLL.

A proposed solution:

Have a configuration variable in blakserv.cfg that contains the offset required. This can be adjusted at server startup. Perhaps have the system give a warning if the current offset will expire within a few months. Alternatively: the server could calculate an offset every time it starts up; this seems like overkill since the bug only strikes once every 4 years or so. This alternative would also create problems with the time stamps on globe postings if they are older than the offset.
The scripting system would have to notified when the value is changed so that it can adjust stored timestamps appropriately.
As part of the login handshake, the server can pass the current offset to the client. The client stores this value and uses it to offset any timestamps sent to it.
Globe postings and mail messages could use strings for timestamps instead of integers. This would increase the amount of bandwidth required to send the information. This could cause problems, since a large amount of mail messages can knock a person offline; using strings would reduce the number of messages that could be passed at one time