I just finished my new library. ezTime — pronounced "Easy Time" — is a very easy to use Arduino time and date library that provides NTP network time lookups, extensive timezone support, formatted time and date strings, user events, millisecond precision and more.
(It can be installed using the Arduino Library Manager, just search for "ezTime")
Thank you for this library, I also had headaches with timezone and DST.
I am currently playing with it.
I have found that there is a problem with the New-Zealand timezone of your example as the library is always setting it as UTC. It is working with some other time zones.
In my application, I try tu use geoip by default, but it might not always work. I would like then to add a way for the user to set the timezone manually in the web gui. Do you have an idea of best practice on how to do it ? I have seen that there are a lot of time zones and it is not a good idea to include them all in a drop down list.
Also, I am using ntp to update a ds3331 rtc once a day as I want to be sure to have a good time even without a network connection. Obviously, in this case, I am using the RTC as a default time source.
Do you plan to add a notion of 2 time source (main and secondary) ? Do you accept contributions to the library ?
I am setting the time zone in the setup(). But I need to know if it has failed later, when I am processing the web gui. I didn't find a way to get the status later. So for now, I set a flag. Is there a method somewhere in the library for this ?
I really like the features.
However, Unless i'm missing something, or there is a way to configure the TimeZone object (which is entirely possible, and if so please correct me), the time_t values presented to the user are not properly reflecting an epoch based timestamp.
Jack's Timezone library has this same issue.
In unix/linux a time_t is always a timestamp relative to a single epoch and is independent of and not affected by any timezone information or offsets.
The timestamp is self-contained and does not depend on any other information/knowledge to be able to convert it to a local time for output other than knowing the desired output local timezone information.
So the time_t value is the same value no matter where the person is on the planet and their local timezone rules and offsets.
This is critical since it allows a timestamp saved in one timezone to be used in another timezone without having to know what timezone it was saved in.
What I'm seeing in exTime is that the time_t value presented to the application from a function like now() appears to be altered depending on the timezone.
i.e.
UTC.now() is not returning the same as local.now()
This breaks the concept of the epoch based time_t
For example, the now() function which returns a time_t timestamp should return the exact same value in every timezone since the seconds from the actual epoch doesn't change just because a persons locality has changed. It needs to work this way to ensure that time_t values are self contained.
This affects other things in the library like what was mentioned in issue #10
Since if all time_t values represent a time from the same epoch, you need convenient way to create the time_t value when providing localized broken down time values. The way to do this is have makeTime be timezone aware so it can take a localized input and generate the proper time_t value.
So IMO, the way the library should work is:
all time_t values presented to the user application should be based on the same epoch
(i.e. a unix time_t value, the number of seconds that have elapsed since 00:00:00 Thursday, 1 January 1970, Coordinated Universal Time (UTC), minus leap seconds.) and are not affect by timezone.
Internal "localized" time_t values can be used for library calculations purposes but should never presented to the user application.
makeTime() should be timezone aware.
This is the convenient way to get from the localized broken down time values to a proper unix time_t timestamp that represents that local time.
This has the potential to simplify some things in the library and the application.
It ensures that all the time_t values used by and reported to the application are all always unix time_t values.
I think it would also still allow compatibility with the exiting TimeLib API since that library didn't support timezones.
But with this change, it should be possible to simply set & use a local timezone with standard time_t values by simply changing the default timezone. This allows localized broken down times values to be created for output in functions like dateTime() as well as used by MakeTime() all while still using proper unix time_t epoch based timestamps.
This would allow doing things like calling now() or tzobj.now() and feeding those time_t values directly into hour(t) or txobj2.hour(t) to get the localized value without having to do any sort of time_t conversions in the application prior to calling functions like hour(), min() etc..
Applications would also be able to import time_t values from other sources and use them directly with output functions like
txobj.hour(time_t_from_a_unix_machine) to provide a localized conversion for an externally created time_t.
And the application can call timezoneobj.makeTime() to generate proper epoch based time_t value by supply the localized broken down values.
I added a comment related to time_t handling on github in response to a makeTime() processing issue:
My comment briefly describes some things that could (IMO, should) be done to allow ezTime to handle & process time_t values the way unix/linux systems do.
I'll soon add another github issue further describing these modifications.