PureBasic Forums - English

Is there a reason to use a macro and variables?
We can then simplify a little more

idle wrote:If I change my system time to display UTC , I still get the correct value

My Bad, i have used linux, sorry

ts-soft wrote:

idle wrote:If I change my system time to display UTC , I still get the correct value

My Bad, i have used linux, sorry

kind of looked like windows to me, but you still didn't say how the time was wrong.
maybe I'll just go along with Douglas Adams “Time is an illusion. Lunchtime doubly so.”

Marc56us wrote:Is there a reason to use a macro and variables?

There is no technical reason to use a macro and variables.

However, using the macro has the advantage that its name is self-explanatory -- in contrast to time(). And it was not my intention anyway to post code as simple as possible.

The part with the variables were not meant for copy-and-paste for general use, but only for demonstration purposes. Using a variable named 'local' stresses the point that this is the local time.

Marc56us wrote:We can then simplify a little more

Your code can be simplified even more. Since it doesn't contain any variables, EnableExplicit is not necessary.

With PB 5.62 and 5.70 beta 1 on Windows 10 version 1803, the following code shows always 2 here (where we currently have CEST), regardless of the value of RealTimeIsUniversal in the registry. If the computer clock has been adjusted so that Date() yields UTC, then of course time() does not yield UTC anymore.

Little John wrote:With PB 5.62 and 5.70 beta 1 on Windows 10 version 1803, the following code shows always 2 here (where we currently have CEST), regardless of the value of RealTimeIsUniversal in the registry. If the computer clock has been adjusted so that Date() yields UTC, then of course time() does not yield UTC anymore.

Code: Select all

ImportC ""
   time(*tm=#Null)
EndImport

Debug (Date() - time()) / 3600

Can you tell me how it compares to my OP? That's what I mean't to ask but didn't state it clearly.
There's a DST field and I don't know if I need to account for it or not.
It seemed to work when I changed my PC date to a time with DST in effect but I wanted confirmation

Hello idle,

I am sorry if I didn't understand you properly.

The code in your first post of this thread works as expected on my German Windows 10 system. I.e. the UTC() function yields 1 hour less than PB's Date() function when DST is not in effect, and 2 hours less when DST is in effect. This is always the case, regardless whether the value of RealTimeIsUniversal in the registry is 0 or 1.

This means, analogously to what I wrote in my previous post, that your function UTC() actually yields UTC, as long as the clock setting of the regarding computer is normal, so that PB's Date() function yields the local time (with or without DST in effect).

Hi Little John,
Thanks, I thought it was correct but I was confused when it was pointed out that time() returns UTC
I had misunderstood what gmtime() does and had thought it was a required step to convert the time to UTC

wilbert wrote:It shows the correct UTC time here (MacOS).
You could also use the PB functions to format.

Code: Select all

ImportC "" 
  time(*tm)
EndImport

Debug FormatDate("%dd %mm %yyyy %hh:%ii:%ss UTC", time(#Null))

Thank you for this - just what I was looking for