Background on llGetTimeOfDay delay ?

Hello scripters,

Maybe someone can help me out here.

The situation:

To make correct astronomical calculations I tried the available time functions.

llGetWallclock, llGetGMTclock and llGetTimestamp give accurate results, but llGetTime OfDay is approximately 65 seconds ahead. Substracting timeDilation (assuming the dilation is expressed in minutes, and is actually involved in the difference) gives a remaining 5 seconds difference. Not really something to write home about, but I want to understand how this actually works.

I tested this in several sims with several TimeDilations, but the difference was 62 to 65 seconds ahead, even with substantial timeDilations. There was no reboot of the testsims previously to or during the measurement. The script used is at the bottom of this message.

The questions:

- Why is llGetTimeOfDay ahead?
- Is there any relation with timeDilation?

I am also trying to find how llGetSunDirection relates to llGetTimeOfDay and whether it has the same delay or not. I am making a script for this right now but if anyone has information I would be very very happy!

Greetings and lots of fun
LillyX

---------------
TESTSCRIPT

// TimeCheck
// 23 jun 07

float SampleRate = 1; // 1 sim Sun hour = 10 min = 600 sec

default
{
state_entry()
{
integer i;
llSay(0,"TimeCheck Activated . . .";
llSay(0,"Updated every "+(string)SampleRate+" seconds";
llSetTimerEvent(SampleRate);
}

timer()
{ float fps = llGetRegionFPS();
float timeDilation = llGetRegionTimeDilation();

integer SimTime = (integer)llGetTimeOfDay();
integer SimHour = SimTime/3600;
integer SimMin = (SimTime%3600)/60;
integer SimSec = SimTime%60;

integer Time = (integer)llGetWallclock();
integer Hour = Time/3600;
integer Min = (Time%3600)/60;
integer Sec = Time%60;

integer GMT = (integer)llGetGMTclock();
integer GMTHour = GMT/3600;
integer GMTMin = (GMT%3600)/60;
integer GMTSec = GMT%60;

string TimeStamp = llGetTimestamp();
string TimeOfDay = (string)SimHour+"h"+(string)SimMin+"m"+(string)SimSec+"s";
string STime = (string)Hour+"h"+(string)Min+"m"+(string)Sec+"s";
string GMTTime = (string)GMTHour+"h"+(string)GMTMin+"m"+(string)GMTSec+"s";

llSay(0,"TimeOfDay: "+TimeOfDay+
" Wallclock: "+STime+
" GMT: "+GMTTime+
" TimeDilation: "+(string)(timeDilation*60)+
" Stamp: "+TimeStamp);

}
}

I can't speak much to why llGetTimeOfDay() is off by 65 seconds, but I can tell you that llGetTimeDilation doesn't return a number of seconds. It returns a ratio of how fast time is currently running to how fast it "should" be running. Normally you get 1.00, but sometimes you get lower numbers. You will never see a dilation greater than 1.00.


Now for some guessing:

As far as I understand, llGetTimeOfDay() is handled via an internal counter in the sim updated once per second. Maybe the sim doesn't take into account the time required to load its database when starting up? Or maybe this discrepancy is due to short time dilation spikes?

Thanks for your thoughts Lex,

As a ratio not exceeding 1.0 one should expect the time to be behind instead of ahead.

It seems the llGetSunDirection is ahead too by approximately the same amount. I check this by taking the the time of Sun's meridian passage (llGetSunDirection.x == 0).

This is funny, because as I undertand it, the sun is not a region object but global, and the llGetTimeOfDay is region bounded.
So if llGetTimeOfDay gets a offset due to region restart and llGetSunDirection due to ??? (grid restart?) the offsets are likely to be different and not linked.

However, my working assumption for now will be that the llGetSunDirection checks the llGetTimeOfDay to apply the region offset to the llGetSunDirection. Which would be very convienient.

Greetings
LillyX
(Living 65 sec. ahead of time and
having lots of fun with lost Second Seconds)

But on private estates one can set the whole sim to have a sun position such as "always midnight" so I think the sun is regional... but by default and across the mainland the sun moves the same in every sim. Well, the same, modulo any variations in whatever causes the mysterious 65 second gap, presumably.