Talk:LlGetGMTclock

From Second Life Wiki
Jump to navigation Jump to search

I am curious as to why this is in Category:LSL God Mode Riku Highfield 11:33, 15 November 2010 (UTC)

Wiki engine bug. -- Strife (talk|contribs) 10:51, 16 November 2010 (UTC)

Slightly incorrect terms used by LL...

At the time of writing (Feb 2025), the designation once known as "GMT" — for "Wikipedia logo"Greenwich Mean Time — is not a strictly correct reference to the time returned by this function. Actually, the time retrieved is very likely UTC ("Wikipedia logo"Coordinated Universal Time), which is not quite the same thing.

For practical purposes, however, in the UK both designations are commonly used interchangeably; other countries, although on precisely the same timezone as the UK and using the same 0º meridian that passes through the Greenwich Observatory in England, rarely call their own legal time "GMT". Instead, they either reference it as UTC (a neutral, scientific term, free of any nation-specific designations), or use a local designation. The bits of Europe that are in UTC, but not part of the UK, usually refer to it as WET (Western European Time), except for Ireland, which legally defines its local hour as Irish Mean Time. Additionally, there are daylight savings to take into account (even in the UK!), which means a difference to be taken into account.

It is unknown what llGetGMTclock() returns when daylight savings is in effect in the UK. If it works like llGetTimestamp(), then it's highly likely that this function is really returning UTC.

If not — i.e., if this function just returns the local time in California minus eight hours — then it's even more confusing, since daylight savings start and end on different days in the UK and the US! There would therefore be a series of days, twice per year, when this function would not return GMT at all, but some confusing time that wouldn't be used anywhere in the UK, Ireland, or countries using WET.

By contrast, UTC is UTC, 365.25 days a year, 24 hours a day.

Probably this function should be renamed to llGetUTCclock() instead, which would be more reasonable and accurate.

Then again, maybe I'm the only one really caring about all of the above! 😅

Gwyneth Llewelyn (talk) 12:36, 1 February 2025 (PST)

Why return... a float?

If the time is 'truncated to a second' (as opposed to llGetTimestamp(), which returns a string — but with millisecond precision!), this means that the value returned could easily be just an integer. Note how it's defined as 'the number of seconds since midnight', which will never be greater than 86400, correct? Even 86400000 (for millisecond precision) fits neatly in a 32-bit signed integer. A float, in LSL2, would only be needed to present microsecond precision, which I'm quite sure LL won't ever allow, since the smallest period of time that can be measured is the duration of one frame of simulator time. When there are no delays (popularly known as 'server lag'), there are 45 simulator frames per second, which means that each will last about 0.0222... seconds. That's the finest time resolution that we can get from a simulator in the SL Grid; for practical purposes, it's pointless to give any precision under 23 milliseconds. Thus, an integer would be more than adequate for this function.

Even if the reasoning behind returning a float is that some calculations might require floating-point division — which is certainly true in many use-cases — it's far easier to cast the integer into a float if and only if it's needed. But in most use-cases this will simply not be true!

Of course, if LL ever considers to have this function returning fractional seconds — which I would thoroughly relish upon! — then I'd withdraw my objection.

Gwyneth Llewelyn (talk) 12:57, 1 February 2025 (PST)

Good questions, along with the one before, we can only guess (and I suppose for GetGMTclock we could check during daylight savings time if the difference between GMTclock and Wallclock changes). Renaming or sanitizing function signatures is not possible though, once a function makes it to the main grid and can be used it's essentially forever like that, any changes could break existing content. See the whole XorBase64 string function debacle, 3 versions of which only 1 works correctly. --Frionil Fang (talk) 01:51, 2 February 2025 (PST)