UTC / GMT Time is not correctly computed

Getting Started Newbie Questions
#1

Hello,

I am creating an application that generates a notification (using the Notifications plugin). As we know, it requires to indicate the time in UTC time. For this reason, my App calculates the difference between local time and UTC (this is Spain and right now the UTC / GMT difference is + 2).

In fact, if I try to show the current local time and the current UTC time, it does it correctly. But when trying to calculate the DIFFERENCE between both time uses, it does not do it correctly or I’m making some mistake that I do not know.

We see it with this simple example:

print("Local Time: ", os.date( “*t” ).day, os.date( “*t” ).hour, os.date( “*t” ).min)

 

print("UTC Time: ", os.date( “!*t” ).day, os.date( “!*t” ).hour, os.date( “!*t” ).min)

This sentences present (correctly) the following output:

Local Time: 27 9 34

UTC Time: 27 7 34

As we can see, the difference of 2 hours is confirmed (9 and 7).

But, if I compute the difference like this:

print("Local secs: ", os.time(os.date( “*t” )),   "UTC secs: ", os.time(os.date( “!*t” )),   "Dif.: ", os.difftime( os.time(os.date( “*t” )), os.time(os.date( “!*t” )) ) / 3600)

The output is:

Local secs: 1522136070 UTC secs: 1522132470 Dif.: 1

Just only 1 hour!!

Please, I will appreciate any help in this.

Thanks!

J.M.

#2 
local t1 = os.date( "\*t" ) local t2 = os.date( "!\*t" ) t1.isdst = true -- or false t2.isdst = true -- or false

if you set the same value for isdst parameter os.difftime compute value you expected. I don’t know why this happen.

ldurniat

#3

Thanks, Idurniat!!!

I’ll try this as a temporary solution.

But I’ll wait for an official response to the origin of the problem, if this requires other changes.

J.M.

#4

I was going to ask if your timezone is using daylight savings time? If so you have to compensate for it.

As for why it works I can’t be certain. The os.time() and os.date() functions are straight from Lua and are just wrappers around the Unix C Library time and date functions. They are well tested.

I suspect that os.time() may not be compensating for DST where os.date() may be compensating for it (or visa versa). I would print out the values of .isdst in both test cases and see if you can determine where DST is and isn’t being applied.

Rob

#5

Hello, Rob!

Yes, here in Europe we apply daylight savings time, and just 5 days ago we switched from GMT +1 to GMT +2.

As you say, it is strange that such a generic routine does not apply that control equally …

However, and knowing that I can apply the solution that ldurniat offers, I will solve it like this.

Thank you very much to everyone for your help!

J.M.

#6

I don’t use UTC for notifications, instead I base on amount of seconds in the future it is and use that.  This way you take time zones out of the equation.

So if you want to schedule a notification for 24 hours time you would 

notifications.scheduleNotification( (60 \* 60 \* 24), { alert = "my message", badge = 1 })
#7

Hi,

This is a good idea, too.

Thanks!

J.M.

#8 
local t1 = os.date( "\*t" ) local t2 = os.date( "!\*t" ) t1.isdst = true -- or false t2.isdst = true -- or false

if you set the same value for isdst parameter os.difftime compute value you expected. I don’t know why this happen.

ldurniat

#9

Thanks, Idurniat!!!

I’ll try this as a temporary solution.

But I’ll wait for an official response to the origin of the problem, if this requires other changes.

J.M.

#10

I was going to ask if your timezone is using daylight savings time? If so you have to compensate for it.

As for why it works I can’t be certain. The os.time() and os.date() functions are straight from Lua and are just wrappers around the Unix C Library time and date functions. They are well tested.

I suspect that os.time() may not be compensating for DST where os.date() may be compensating for it (or visa versa). I would print out the values of .isdst in both test cases and see if you can determine where DST is and isn’t being applied.

Rob

#11

Hello, Rob!

Yes, here in Europe we apply daylight savings time, and just 5 days ago we switched from GMT +1 to GMT +2.

As you say, it is strange that such a generic routine does not apply that control equally …

However, and knowing that I can apply the solution that ldurniat offers, I will solve it like this.

Thank you very much to everyone for your help!

J.M.

#12

I don’t use UTC for notifications, instead I base on amount of seconds in the future it is and use that.  This way you take time zones out of the equation.

So if you want to schedule a notification for 24 hours time you would 

notifications.scheduleNotification( (60 \* 60 \* 24), { alert = "my message", badge = 1 })
#13

Hi,

This is a good idea, too.

Thanks!

J.M.