Closed G6EJD closed 6 years ago
Thank you, I was just about to come on here about the same issue
It's easy to correct as I show above.
In Portugal the time has also changed. The system continues with the time unchanged. I'll change the program line. Thank you for the advice. Edward
It's easy to correct do as I show above.
Yes buddy, already done it when you posted and works fine here.
Thanks. I will have a look at it very soon.
Sorry guys, it isn't as simple as the change above. It would not show correct times for US timezones that use Day Light Savings time... thus the dstOffset. It looks like we will need to add a we configuration checkbox that specifies weather you use DST or GST offset.
The documentation on geonames is not that great, but they say this:
rawOffset: the amount of time in hours to add to UTC to get standard time in this time zone. Because this value is not affected by daylight saving time, it is called raw offset. gmtOffset: offset to GMT at 1. January (deprecated) dstOffset: offset to GMT at 1. July (deprecated)
So both dst and gmtoffset values are depreciated, but rawOffset looks like it provides the answer.
Alternatively, the ESP core 2.4.2 now supports correct time-zone setting with setenv, so for the UK I would use: setenv("TZ", "GMT0BST,M3.5.0/01,M10.5.0/02",1); // You must include '0' after first designator e.g. GMT0GMT-1, ',1' is true or ON
Then all it needs is a time zone string in the settings.h String TimeZone = "GMT0BST,M3.5.0/01,M10.5.0/02";
Thanks for the details, I have gone over there documentation in the past. The problem is rawOffset does not provide the correct offset for US timezones -- they actually tend to match gstOffset. Like I said, I think there will need to be a configuration flag for the value to use. I know they both say depreciated, how ever if I call the service directly and test it, the value isn't correct for other timezones around me.
Here is an example: This is for Salt Lake City Utah, USA and currently their timezone is GMT -6 -- if you look at the response:
http://api.geonames.org/timezoneJSON?formatted=true&lat=40.8&lng=-111.8&username=demo&style=full
' "gmtOffset": -7, "rawOffset": -7, "timezoneId": "America/Denver", "dstOffset": -6,`
The only thing that would give them the correct time is the dstOffset.
It's off behaviour, looks like a configuration setting then to include or not. Setting the timezone correctly now in the ESP8266 or ESP32 is simply: setenv("TZ", "GMT0BST,M3.5.0/01,M10.5.0/02",1); Then get the time, it always display the correct value derived from the rules.
String gettime(){ time_t tnow = time(nullptr); return String(ctime(&tnow)); }
Yeah, not an easy solution for the end user that does not know how to compose that line. The goal with the project here is to make it as simple for anyone to load the firmware and pull up the configuration page. As it stands today, nobody has to edit the settings.h file or ANY code to load it and configure it.
As for "off behavior" -- I see configurations all the time that allow the user to specify if they use DST.
It looks like their API has an error to me. I can't think of a situation where -7 and -6 would exist and clearly only -6 is correct.
This is the reference I use: https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv
Oh, OK, so they say Denver is 7 hours from GMT, which will be the case when DST ends, so it's DST offset -1 hour during DST.
Yeah, that is it. Timezones are a real pain especially when trying to cover a global solution. At this point I think the simplest solution for the end user would be to allow them to check or uncheck a DST option. What do you think?
I agree.
If some of you have time to test the dev branch for 2.4 -- that would be awesome.
https://github.com/Qrome/marquee-scroller/tree/2.4
I have posted the option for DST -- the default can be set in the settings.h and it can be configured with the web interface. If IS_DST = false then it will use the rawOffset and this should fix the issue with those timezones in Europe having issues.
I've been reading the geonames API documentation some more and determined this: rawOffset gives the fixed timezone. dstOffset gives the civil time offset from GMT on July 1st gmtOffset gives the civil time offset from GMT on January 1st
So for Denver: rawOffset = -7 indicating the timezone dstOffset = -7 gmtOffset = -6 which means that daylight saving time is in use in January
From these values the DST value can be determined e.g. mod(rawOffset-gmtOffset) = -1 which is correct. If (rawOffset != gmtOffset) then DST is active or if (rawOffset < gmtOffset) then DST Is on and time_offset = gmtOffset else time_offset = rawOffset
The documentation implies they don't send DST active status as it can be determined from the supplied values.
In the case above gmtOffset and rawOffset are both -7 the only value that would help determine the correct time is the dstOffset as you can see it's value is -6. The case you mentioned above is not correct for the America/Denver scenario.
"gmtOffset": -7, "rawOffset": -7, "timezoneId": "America/Denver", "dstOffset": -6,
As you can see the values listed for the response for Denver will not give you the correct time. I have also read through their documentation a while back and I do think they haven't implemented their service as they think they have. For those time zones that use DST -- the DST value is still needed. Please check out the 2.4 dev branch if you have time.
Anyone interested in helping test the fix, please take a look at the 2.4 dev branch here:
Yes, I made a small mistake, but this fixes it, now working for Denver, London and Moscow: String gmtoffset = (const char)root["gmtOffset"]; String dstoffset = (const char)root["dstOffset"]; if (gmtoffset > dstoffset) offset = dstoffset; else offset = gmtoffset;
Denver, CO is still in DST until 04-Nov, so it detected DST was on and chose -6, next weekend it will go back to -7.
Some countries like India use 5.5 hours, so it can't work exactly for them unless it's a float elsewhere.
This is my final code correction: String offset = (const char)root["gmtOffset"]; String dstoffset = (const char)root["dstOffset"]; if (offset > dstoffset) offset = dstoffset;
Will this work in all regions? Will the DST offset ever be greater than the GMT? I will look at this more later tonight.
Well I tried it for Denver (-6) still in DST, London (0) not on DST, Moscow (+3). Or on DST and I was going to try India but OWM provides no data for that region, I was surprised by that. The gmt test determines if the county is out of DST and DST test in DST
I was considering making the auto detection of the DST but after talking with some friends from EU -- there is talk that some regions may want to select DST. This will give the user the option to either display gstOffset or dstOffset with the checkbox.
Thanks.
There is some discussion in the EU on scrapping moves to and from DST and staying permanently on DST but until the business and banking industries can align and the EU parliament decides then that’s just fanciful talk for now , I’m ambivalent and will leave mine on auto detect, in any case what ever the DST decision is, when they do decide all the sites like geonames will have to align, actually as fanciful as the idea is, how would they ever align data sources a weather forecast that’s an hour or more out, don’t think so and that’s at the trivial end of the scale.
Yeah, you are probably right about the fanciful idea of having geonames align their service and Data Sources -- in that case both auto detection and manual mode may hit some bumps.
Also, if you don't take the 2.4 code as I am about to merge it to Master -- you will miss out on some of the other recent changes including displaying the day of the week.
Ok, I have merged the recent changes to Master and made a 2.4 release. Thanks for the feedback and help. I am closing this for now. Any new issues with TimeZone and DST -- let's create a new thread. Thanks.
Could you resize the case and make it 1mm wider please, as the latest displays are slightly longer, the only way I can get them to fit is to melt off 1mm, clearly a spread in production of the displays, either way length and width it’s a very tight fit and could usefully be expanded to cope with the spread.
UK time changed today, Easily corrected by seeking 'gmtOffset' instead of the fixed value of 'dstOffset' In Geonameclient.cpp modifiy line 81 from:
String offset = (const char)root["dstOffset"]; To: String offset = (const char)root["gmtOffset"]; //Now uses the varying gmtOffset value
This corrects the issue.