[Gambas-user] Best way converting dates into strings forth and back

[Tobias Boege]

On Sat, 11 Dec 2021, Jussi Lahtinen wrote:
> Challenge for anyone who thinks this is easy or that I merely don't
> understand how it works.
> Either use your own written calendar or the attached GAlarm (or go to the
> software farm and download GAlarm). I challenge everyone to try to fix it,
> or just test your own calendar in a virtual machine with timezone changes.
> 
> Set up:
> Add some alarms with different dates, and put the same dates into a text
> file for later comparison.
> 
> Four tests:
> 1. GAlarm (or your own program) running when time jumps forward (IE set the
> date of the virtual machine so that it is just about to change timezone and
> wait).
> 2. The program not running when time jumps forward.
> 3. The program running when time jumps backwards.
> 4. The program not running when time jumps backwards.
> 
> Goal:
> None of these tests should influence the set dates. If the alarm is set up
> to go off at 1.2.2023 12:00, it should do it 12:00, not 13:00, etc.
> 
> If you can make this work in all of those cases, you will get your name in
> the GAlarm authors with special appraise. Also you will get this working
> handy calendar for free. I'm not saying it is impossible, but surely such a
> headache that I have given up on it for a moment. Way too frustrating.
> Also, please do not report any success until you really have tested it. So
> many times I have felt I got it and have fixed it...
> 

I'm not interested in attempting to solve this but my thoughts are these:
there is a difference between "points in time" and "calendar datetimes".
The former are specified by a number of units (at the required scale --
seconds, milliseconds, ...) from a reference point in time. I do believe
that this is not difficult. E.g., my laundry will be done in 85 minutes.
That's an alarm which is not influenced by the earth's orbit, my timezone
transgressions or politics.

But if you want to deal with "calendar datetimes", i.e., combinations of
a date and a time arranged between humans, it gets complicated. If you
agree on a date and a time for an appointment now, you simply cannot
calculate right now how many seconds in the future this appointment will
take place. E.g., my job interview is on "12 July 2022 at 12:00".
The time is of course understood by my potential employer and me to
be whatever the local time is on that day. If we expect to be in different
timezones at that moment, we should make two datetimes and check that we
believe that they denote the same point in time -- but we can really never
be sure until we reach that point in time. Alternatively, we may write
"12:00 CEST" to fix a reference timezone.

Sure, you can take care of time zone changes, leap days and unleap days
if you're careful enough while converting such a stringified datetime into
a point in time. But what you cannot anticipate with certainty is whether
daylight saving time will be abolished before the appointment, rendering
your computations invalid, or the introduction of leap seconds in the
months between scheduling the appointment and it taking place.

I see no other solution to scheduling calendar datetime alarms than to
rely on your operating system to always be up to date enough on these
matters and then to regularly check the current datetime in your program.
Unless more rules and factors are added which influence the local datetime
(wherever that is for you when it matters!), you should know about all
the relevant leap seconds when you enter the month in which the alarm is
supposed to go off. Timezone is still a bit of a headache, especially
when you're traveling. Can we have a meetig on 27 March 2022 at 2:30am?
People in the US can, people in Germany can't. The week after it's the
opposite. But the closer you get to the datetime, the more certain you
are about at which point in time it will happen.

Basically, if you want to solve this properly (meaning without literally
once-in-400-years edge cases), keep a stringified version of your appoint-
ment datetime, rely on your operating system / NTP daemon and evaluate
that string representation in the way a human would do in a high enough
frequency to check if your appointment is SOON ENOUGH for all factors
influencing the interpretation of the datetime to have settled. Then you
may convert it to a point in time and set a Timer for it.

Best,
Tobias