llGetDayLength() reports incorrect time when sitting on an object
tracked
AlettaMondragon Resident
This is an elusive bug because it doesn't happen with the default 4-hour day length, but it can be reproduced consistently with any other day length.
If you put this script into an object:
default
{
state_entry()
{
llSetTimerEvent(1);
}
timer()
{
integer daylength = llGetDayLength();
llOwnerSay((string)daylength);
}
}
(timer event can be more than 1 second if you want it less spammy)
1: Make sure the parcel's day length, as shown in About Land > Environment, is the default 4 hours.
2: Wear the object while standing, you will see that the reported day length will be correct, as shown in About Land > Environment. (14400 seconds = 4 hours)
3: Then sit on an object. The script will still report the correct day length.
4: Change the parcel's day length to any other value while you're still sitting.
5: The script keeps reporting the 4-hour day length.
6: Stand up and the script will report the correct day length, as shown in About Land > Environment.
This means for some reason llGetDayLength() keeps reporting the default 4-hour day length when the avatar wearing the script is sitting on an object, no matter what the parcel's day length is set to.
I know there is a newer llGetEnvironment() function that can retrieve parcel day length, I tested it and it does not have this issue. However I believe it is less costly to run llGetDayLength() and llGetTimeOfDay() separately every second in a watch than calling llGetEnvironment() and then retrieving the time of day and day length values from the list, so it would be crucial for this function to work correctly under all circumstances.
Log In
Maestro Linden
updated the status to
tracked
Maestro Linden
AlettaMondragon Resident thanks for the report. I can reproduce this with your script on Second Life Release 26.4.0.37384746592 on Second Life Server 2026-09-28.36457939353.
I suspect we're seeing the same underlying issue as this one for llGetTimeofDay(), which was fixed a few releases ago:
That case was also specific to the LSL function call not returning the correct value for the parcel's environment if
both
of these conditions are met:- the script is attached to an avatar
- the avatar is sitting on an object located in the parcel (not directly on the ground)
I believe the returned environment value is for the avatar's sit position on the seat's linkset. So if the avatar is sitting on an object with a sit target of <0,0,1>,
llGetDayLength()
returns the environment setting at position <0,0,1> in the region, rather than the environment at the seated avatar's transformed position.AlettaMondragon Resident
Maestro Linden That seems right. On a parcel that includes the 0,0 coordinates and has a custom day length, the reported day length value is correct while sitting on an object. It might very well be that while the same issue Emma has found with llGetTimeOfDay() got fixed, this one is doing the same thing and it remained unidentified until now. One thing for sure, now my watch that I wear all the time I'm online takes a minimum of 0.003591 ms script time instead of 0.003022 ms because of using llGetEnvironment() and then fetching the day length from the list, so it's not ideal to use this workaround.
Another thing by the way, do you know of any report on a personal day cycle applied with "Apply only to myself" not following the custom parcel day length and offset at all? That is, if the parcel has a 24-hr day length for example, your day cycle in the viewer will still follow the 4-hr day length, apparently. (This is the main reason I monitor parcel day time everywhere I go.)