Page 1 of 1

Data changes according to UTC, not Local Time **solved**

Posted: Mon Aug 05, 2019 11:51 am
by cphMichael
My Meteobridge Pro upload data to Twitter every hour.

I would expect the data to change at 00:00 but as you can see below it first changes at 02:00.

It seems like the Meteobridge follow the UTC and not local time.

5/8-2019 kl. 02:00 - Sunrise 05:23, Sunset 21:09, Length 15:47 (-1:46)
5/8-2019 kl. 01:00 - Sunrise 05:21, Sunset 21:11, Length 15:51 (-1:42)
5/8-2019 kl. 00:00 - Sunrise 05:21, Sunset 21:11, Length 15:51 (-1:42)
4/8-2019 kl. 23:00 - Sunrise 05:21, Sunset 21:11, Length 15:51 (-1:42)

Regards

Michael

http://frederiksberg-vejret.dk

Re: Data changes according to UTC, not Local Time

Posted: Tue Aug 06, 2019 3:48 pm
by admin
Did you set time zone on "System" tab, pressed "save" and did a reboot?

Re: Data changes according to UTC, not Local Time

Posted: Wed Aug 07, 2019 1:33 pm
by cphMichael
I have attached a screendump of the Localization info.

The displayed UTC and Local Time is correct.

You can see the 'live' Twitter update here:

https://twitter.com/frbvejret

Re: Data changes according to UTC, not Local Time

Posted: Fri Aug 09, 2019 12:07 am
by admin
What does your twitter template string look like?

Re: Data changes according to UTC, not Local Time

Posted: Fri Aug 09, 2019 8:57 am
by cphMichael
It is setup to 'After every full hour".

Can that be the issue - so it add an extra hour before uploading the data?

I will change it to "Before every full hour" and see if that change it :-)

This is the Twitter string:

[D]/[M]-[YYYY] kl. [hh]:[mm] - [th0temp-act.1:--]˚C - [th0hum-act.0:--] pct - [rain0total-sumday.1:--] mm - [thb0seapress-act.0:--] hPa - Sol op [mbsystem-sunrise], Ned [mbsystem-sunset], Længde [mbsystem-daylength] (-{*([mbsystem-daylengthmax=mins.0]-[mbsystem-daylength=mins.0])/60*0t}:{*([mbsystem-daylengthmax=mins.0]-[mbsystem-daylength=mins.0])%60*00t})

Re: Data changes according to UTC, not Local Time

Posted: Mon Aug 12, 2019 12:55 pm
by cphMichael
Unfortunately, changing from "After every full hour" to "before every full hour" didn’t solve the problem:

12/8-2019 kl. 02:59 - Sunrise 05:36, Sunset 20:54, Length 15:18 (-2:15)
12/8-2019 kl. 01:59 - Sunrise 05:36, Sunset 20:54, Length 15:18 (-2:15)
12/8-2019 kl. 00:59 - Sunrise 05:34, Sunset 20:56, Length 15:22 (-2:11)
11/8-2019 kl. 23:59 - Sunrise 05:34, Sunset 20:56, Length 15:22 (-2:11)
11/8-2019 kl. 22:59 - Sunrise 05:34, Sunset 20:56, Length 15:22 (-2:11)

https://twitter.com/frbvejret

Re: Data changes according to UTC, not Local Time

Posted: Mon Aug 12, 2019 2:29 pm
by ConligWX
cphMichael wrote: Mon Aug 12, 2019 12:55 pm Unfortunately, changing from "After every full hour" to "before every full hour" didn’t solve the problem:

12/8-2019 kl. 02:59 - Sunrise 05:36, Sunset 20:54, Length 15:18 (-2:15)
12/8-2019 kl. 01:59 - Sunrise 05:36, Sunset 20:54, Length 15:18 (-2:15)
12/8-2019 kl. 00:59 - Sunrise 05:34, Sunset 20:56, Length 15:22 (-2:11)
11/8-2019 kl. 23:59 - Sunrise 05:34, Sunset 20:56, Length 15:22 (-2:11)
11/8-2019 kl. 22:59 - Sunrise 05:34, Sunset 20:56, Length 15:22 (-2:11)

https://twitter.com/frbvejret
I'm not sure it this would make a difference but there are slight differences in your calculation than what boris had put up in an earlier post space missing "%60*00t" "% 60*00t" and "/60*0t" "/60*00t"

viewtopic.php?p=23384#p23384

Code: Select all

{*([mbsystem-daylengthmax=mins.0]-[mbsystem-daylength=mins.0])/60*0t}:{*([mbsystem-daylengthmax=mins.0]-[mbsystem-daylength=mins.0])%60*00t}

{*([mbsystem-daylengthmax=mins.0]-[mbsystem-daylength=mins.0])/60*00t}:{*([mbsystem-daylengthmax=mins.0]-[mbsystem-daylength=mins.0])% 60*00t}
or does the mbsystem-daylengthmax get its data from an online source which is 2 hours behind(UTC) your local time perhaps?

Re: Data changes according to UTC, not Local Time

Posted: Tue Aug 13, 2019 11:30 am
by cphMichael
Thank you for your reply :-)

The string Boris did in his example display the result as "01:46"

I better like to display it as "1:46" so I removed the '0' from the expression.

You can also see that the Sunrise/Sunset is first updated at 2 am

- - - -

A numerical expression that Meteobridge should evaluate needs to be enclosed by {* and *}. The enclosed expression can also include template variables. This allows to do various computations with numerical data. Resulting value is returned with two decimals. You can define how many digits the return value should have by stating the number of decimals between the * and } when closing the numerical expression. For example, *0} does set number of decimals to 0, which will return a rounded integer value.

- - - -

Regards
Michael

Re: Data changes according to UTC, not Local Time

Posted: Thu Aug 15, 2019 1:29 pm
by ConligWX
cphMichael wrote: Tue Aug 13, 2019 11:30 am
You can also see that the Sunrise/Sunset is first updated at 2 am
but is this information a calculation OR from a website/api? maybe the site it takes it from is UTC or GMT which you are 2 hours infront. if indeed this was a site polled event, the site inquestion will only update at UTC/GMT and perhaps you do not see the update until 2 hours later? just a thought.

Perhaps Boris could tell us where the Sunrise/Sunset data comes from?

Re: Data changes according to UTC, not Local Time

Posted: Sat Aug 17, 2019 10:32 am
by admin
Just released update should have it fixed.

Re: Data changes according to UTC, not Local Time **solved**

Posted: Sun Aug 18, 2019 8:42 am
by cphMichael
The problem is solved.

Thank you very much :D

Regards

Michael