I am almost done with the implementation of ESPCLOCK2, so I will start a series of posts detailing the obstacles encountered and lessons learnt from the project.
The original ESPCLOCK obtains the geolocation of the clock during setup from the user's browser, and use the geolocation to convert to local time using Google's Timezone API. As noted here, this approach hits a major snag as recent browsers started to restrict the use of navigator.geolocation.getCurrentPosition() to Javascript running from SSL-secured websites. Since it would be extremely unlikely for WifiManager to support SSL hosting, another approach is needed.
After considering the alternatives, I think the simplest approach will be to host a simple PHP script on a server. This has several advantages: 1) There are no API keys to muck with. All timezone APIs I looked at require you to register for some kind of API key. 2) You won't be affected by API changes, or the service shutting down. You can run the script from any machine that is properly NTP-synchronized (most OS do it by default these days, even Windows). I am hosting the script here, which is open to public access. It is basically a simple 3-liner:
It takes a timezone string found from the list here, and returns the local time for that timezone. The script has very low memory, network and disk access overhead.
There is still the problem of trying to detect the timezone of the user from the browser during setup. This is done by using Intl.DateTimeFormat().resolvedOptions().timeZone, which is supported by more recent browsers. If for some reason the browser does not support this, the user can always populate the field manually.
The original ESPCLOCK obtains the geolocation of the clock during setup from the user's browser, and use the geolocation to convert to local time using Google's Timezone API. As noted here, this approach hits a major snag as recent browsers started to restrict the use of navigator.geolocation.getCurrentPosition() to Javascript running from SSL-secured websites. Since it would be extremely unlikely for WifiManager to support SSL hosting, another approach is needed.
After considering the alternatives, I think the simplest approach will be to host a simple PHP script on a server. This has several advantages: 1) There are no API keys to muck with. All timezone APIs I looked at require you to register for some kind of API key. 2) You won't be affected by API changes, or the service shutting down. You can run the script from any machine that is properly NTP-synchronized (most OS do it by default these days, even Windows). I am hosting the script here, which is open to public access. It is basically a simple 3-liner:
1 2 3 4 5 6 7 8 9 | <?php if (isset($_REQUEST['tz'])) { $time = new DateTime(); $time->setTimezone(new DateTimeZone($_REQUEST['tz'])); print $time->format('h:i:s'); } ?> |
It takes a timezone string found from the list here, and returns the local time for that timezone. The script has very low memory, network and disk access overhead.
There is still the problem of trying to detect the timezone of the user from the browser during setup. This is done by using Intl.DateTimeFormat().resolvedOptions().timeZone, which is supported by more recent browsers. If for some reason the browser does not support this, the user can always populate the field manually.
Comments
Post a Comment