[Gambas-user] CDate Documentation

[Tobias Boege]

On Tue, 15 Nov 2022, BB wrote:
> 
> On 15/11/22 1:16 pm, Jussi Lahtinen wrote:
> > This is related to what I have tried to explain several times. The date
> > datatype does not contain timezone information, UTC is always used
> > internally and what is shown is adjusted according to the currently used
> > timezone. Thus you can't get correct results like that. It does not work
> > like a paper calendar.
> > 
> > 
> > Jussi
> > 
> > 
> Maybe I am finally starting to see your issue.
> 
> But the date and time are correct in that they are a specific instance. I
> have changed the TZ in Env to several places and it always returns the same
> date and time. What I think here is wrong is that Gambas is just printing
> the Env["TZ"] value, it is not looking at the date and deciding which *local
> timezone* to print based on that date.
> 
> So if you and I agree to meet for lunch in Honolulu at 12:30 America/Hawaii
> next MayDay to both of us the Date value should be 2492170.52083333 and
> should not change no matter what the current TZ is on our respective
> laptops. However when you display that date (in ECT?) it should be
> 1/May/2023 12:30pm _unless you want to see what date/time it would be in
> "your time" or "my time" etc._ Is that what you are getting at?
> 
> AFAIK we dont have a datetime conversion function. Historically, I have used
> a postgres function to do this like "SELECT '2023-5-1 12:30 HST' AT TIME
> ZONE 'ACDT';" as it was easier than doing the complex conversion myself.
> 

Calendar date/time is so, so subtle! I for one prefer the Date as it is in
Gambas: an instant. Its string representation looks different depending on
the timezone it is rendered for and it alone is entirely unsuitable for
presenting the date and time of an appointment to humans, as your LunchDate
demonstrates. We don't care so much about instants, but about the time
relative to the instant our nearest clock shows 00:00 on any given day
(or maybe 03:00 twice a year).

Creating a Date subjects it to your local timezone in that it is subtracted
to yield a UTC timestamp of the instant you meant. Here Gambas is crucially
making an assumption (but a documented one) about what you mean when you
create a Date: you mean that date in the current timezone. This can be
confusing in the commonly cited scenario that you're trying to represent a
local appointment in the future that crosses a daylight savings boundary;
but I feel like I have wrapped my head around this a while ago and have not
been surprised by CDate & co. since then.

Calendar date/time should be its own and separate datatype that can deal
with all the human subtlety associated with it. If we plan to meet N years
from now, who knows if daylight saving will still be a thing? What if the
time lords add another leap second [1]? Both are things that will screw up
an instant such as Date and they are out of control of my small computer
at the moment we make the appointment. They should not screw up a robust
implementation of a calendar date/time because most of our appointments do
not depend on the leap second or daylight saving (my lunch time certainly
doesn't).

The Date in Gambas is for storing dumb instances and doing dumb arithmetic
on them. That's just right for a basic datatype, IMHO.

Best,
Tobias

[1] https://en.wikipedia.org/wiki/Leap_second

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk