<div dir="ltr"><div>Here is the code (see attachment). I hope I didn't mess anything up as I banged my head with this problem...</div><div>Look at LoadAlarms and SaveAlarms in Main module. As you can see the dates are read and written always assuming local date.</div><div>But that does not work. I have tried so many ways...<br></div><div><br></div><div><br></div><div>Jussi<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 28, 2019 at 3:00 AM Jussi Lahtinen <<a href="mailto:jussi.lahtinen@gmail.com">jussi.lahtinen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I found my answer. It's no. I just got this: "10/28/2019 02:04:23.316"<br>
<br>
No idea how you could get that with Date(2019,10,27,2,30) at the beginning!<br></blockquote><div><br></div><div>I meant the output format when any date is converted with cstr. I wasn't clear.<br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course not: you wrote 13:00 *in London*, so you get the time zone <br>
associated with your time (I assume you have a date of course with it). <br>
"13:00" is not always correct, it means nothing per se. It's "13:00 *in <br>
London*" that is always correct, with the time zone.<br></blockquote><div><br></div><div>The problem is, you cannot do that in Gambas at least in any easy way.</div><div>With Date.FromUTC I can put things in UTC, but if I have to use Hour(), Format(), etc, etc it is ruined again.</div><div>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.<br></div><div><br></div><div>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.</div><div>Now when the winter comes, suddenly my calendar says the meeting is 28.10.2019 11:00, because the local time has changed.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">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 <b>automatically interpreted as</b> <u><i><b>current</b></i></u> (which may be different than the original) <b>local time</b>. Only consistent definition is for UTC, it's always the same.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Also, I can write the dates & times as UTC to hard disk, but again when reading them, are they interpreted as <b>current</b> local time, not the local time they was set (and then written as UTC).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Is it any clearer now?</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Jussi<br></div><div class="gmail_quote"><br></div></div>
</blockquote></div>