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

[Rolf-Werner Eilert]

Am 11.12.21 um 17:50 schrieb Jussi Lahtinen:
> 
>       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.
> 
> 
> Yes, if you set 85 minutes and just count down.
> Easy, I agree.
> 
> 
>     The time is of course understood by my potential employer and me to
>     be whatever the local time is on that day.
> 
> 
> Yes, when we do no conversions it is simple. It doesn't matter when we 
> make the appointment (summer or winter)
> "10.12.2021 13:00" is always the correct local time when we meet. Even 
> when it changes relative to UTC. We ignore it, if UTC is not the local time.
> Gambas doesn't really give that option in an intuitive and easy way.
> 
>     Alternatively, we may write "12:00 CEST" to fix a reference timezone.
> 
> 
> Yes, that also works and again, it is something not supported by Gambas. 
> It has local time (which may not be CEST) and UTC.
> However, I think it would be simplest to just assume the given time is 
> in the correct local time. All conversions would be done by the user.
> 
>     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.
> 
> 
> Yes, this is exactly what I have tried to do. The problem is when I have 
> a date stored in a dataype Date at some point, the conversion happens 
> automatically when the timezone changes. Or alternatively you need to do 
> weird unintuitive things like pretend the local time is in UTC and never 
> rely on the actual localization. It gets messy very quickly.
> 
>     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.
> 
> 
> Well, these are exceptions I'm willing to leave to the user to worry.
> 
>     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.
> 
> 
> By using only strings and never date type, you will lose a lot of 
> functionality. But I guess that could work.
> I just hope there would be a clean way to stop all the automatic 
> conversions for dates. Perhaps by forcing Gambas to assume the system 
> clock is in UTC.
> 
> 
> Jussi
> 
> 
> 
> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
> 

In the case of a simple office calendar we should be pretty sure that an 
appointment stored for 13:00 does mean 13:00 local time at that very day.

So when the day of the appointment arrives, the PC on which the calendar 
runs will have the local time running for the user. There will be more 
than one clock in the office, e. g. the mobile, and time can be checked. 
There is local time on my mobile as well (and if I am in another time 
zone, my office local time and the current local time can be shown).

But wouldn't it be easy enough to introduce two different ways of 
processing timecodes, such as there are for ordinary strings and UTF 
strings?

Classic functions -> ordinary strings
String.Class -> UTF strings

Classic functions -> always UTC encoding
Localtime.Class -> Local Date & Time

Or (to enable saving in and restoring from strings) the possibility to 
add "UTC" for UTC time, or one of the timezone codes (like CEST) for 
local time.

By the way, how is it done in Java, Python... Maybe we can learn from them.

Regards
Rolf