[Gambas-user] Daylight "saving" and time zones

[Benoît Minisini]

Le 28/10/2019 à 02:00, Jussi Lahtinen a écrit :
> 
> 
>      > I found my answer. It's no. I just got this: "10/28/2019
>     02:04:23.316"
> 
>     No idea how you could get that with Date(2019,10,27,2,30) at the
>     beginning!
> 
> 
> I meant the output format when any date is converted with cstr. I wasn't 
> clear.
> 
>     Of course not: you wrote 13:00 *in London*, so you get the time zone
>     associated with your time (I assume you have a date of course with it).
>     "13:00" is not always correct, it means nothing per se. It's "13:00 *in
>     London*" that is always correct, with the time zone.
> 
> 
> The problem is, you cannot do that in Gambas at least in any easy way.
> With Date.FromUTC I can put things in UTC, but if I have to use Hour(), 
> Format(), etc, etc it is ruined again.
> Reason I want to use UTC consistently or even better ignore time zones 
> completely is, I need the times & dates written on hard disk mean 
> something despite of being read on different time zones. See below, very 
> difficult to explain.

Date/time are internally stored in UTC in Gambas. If you want to store 
date on a application that can be accessed anywhere in the world, you 
must do the same thing.

Then, you convert these UTC date/time to local time when displaying them 
in the GUI, and convert them back to UTC when reading them from GUI.

In other words, you must not store a date/time without its timezone.

> 
> Now the situation is following, example; I'm in Finland at summer and I 
> plan meeting in winter still in Finland, let's say 28.10.2019 12:00.
> Now when the winter comes, suddenly my calendar says the meeting is 
> 28.10.2019 11:00, because the local time has changed.
> 
> And Tobias here is the problem. When the date & time is written on hard 
> disk, there is no information what was the time zone at the time of the 
> writing. Thus there is no consistent definition for local time. It can 
> be anything and it is *automatically interpreted as* _/*current*/_ 
> (which may be different than the original) *local time*. Only consistent 
> definition is for UTC, it's always the same.
> 
> Also, I can write the dates & times as UTC to hard disk, but again when 
> reading them, are they interpreted as *current* local time, not the 
> local time they was set (and then written as UTC).
> 
> Is it any clearer now?

How do you write your date/time to the disk?

If you use the READ/WRITE instructions, the date/time will be always 
read and written by Gambas in binary form, i.e. in UTC date/time.

Otherwise, if you do that by yourself, you have to store the timezone 
with it manually.

Regards,

-- 
Benoît Minisini