Re: Date function

[Benoît Minisini <benoit.minisini@xxxxxxxxxxxxxxxx>]

Le 06/11/2025 à 00:05, Jussi Lahtinen a écrit :
> Quickly thinking... what if you have "special" timestamp, which is 
> always assumed to be UTC; all inputs are considered given as UTC, user 
> is always considered to be in UTC. IE no matter where the user is, their 
> clock is assumed to show UTC time. And this timestamp is never 
> automatically converted to any other timezone. Also the underlying 
> timezone is never revealed in anyway, then isn't it the same as paper 
> calendar date?
> Really it could be any timezone other than UTC as long as it is 
> consistently always the same.
>
> Jussi

Yes but no. :-)

It's more complex than that.

The Gambas "Date" is actually an UTC timestamp. It's a number of 
milliseconds since a fixed epoch which is assumed to be midnight in UTC.

When converting that timestamp to a date string representation, a pseudo 
Gregorian calendar is used.

It's "pseudo" because:

- It is extended in the past before its invention.

- The real calendar used nowadays is not exactly Gregorian, as it 
sometimes adds one leap second in some years to minimize the difference 
with the Sun movement in the sky relatively to the Earth.

This leap second is normally taken into account by Linux if you 
synchronize your clock with NTP.

But it occurs unexpectedly as far as I know. The Linux kernel maintains 
a boolean that tells if an extra second will be added at the end of the 
current day.

That random leap second prevents Gambas from doing accurate arithmetic 
with dates. So Gambas ignores that, and its date representation do not 
match the modern Gregorian calendar dates.

The only date/time that is ensured by Linux to be accurate when 
converted to its string representation is what the 'Now()' function 
returnsl.

Regards,

--
Benoît Minisini.