Closed witnessmenow closed 4 years ago
Uh oh...
I see Europe/Dublin in the database that I distribute as "Europe/Dublin IST-1GMT0,M10.5.0,M3.5.0/1" so that means it should indeed have changed on the last Sunday in October. Can you verify that you are using the latest version of ezTime? A bug was fixed in 0.7.10 that would cause this to go wrong...
Version 0.7.10 installed. Running code from https://github.com/witnessmenow/arduino-alarm-clock/blob/master/AlarmClock/AlarmClock.ino did not update this morning, or after reboot of device. Not looked into it deeper yet..
Odd. Let's wait a bit to see if more people experienced a problem, and then I'll dive deeper sometime later this week...
Managed to hook up the device to Serial and enable debug "log". Looks like the "posix" string is incorrect reading the readme? Should it not be month 3, M3 first and M10 last, unless I am not reading it correct? See Serial output:
(Booted at 18:43pm)
ezTime debug level set to INFO Waiting for time sync Querying pool.ntp.org ... ERROR: Timeout Querying pool.ntp.org ... success (round trip 26 ms) Received time: Sunday, 27-Oct-19 18:43:07.356 UTC Time is in sync
UTC: Sunday, 27-Oct-2019 18:43:07 UTC Timezone lookup for: Europe/Dublin ... (round-trip 77 ms) success. Olson: Europe/Dublin Posix: IST-1GMT0,M10.5.0,M3.5.0/1 Time in your set timezone: Sunday, 27-Oct-2019 19:43:07 GMT
Or rather, is there no hour set to show the time to change? 1am for March, no time for October?
Unsure?
Just tested for London - and it works fine:
ezTime debug level set to INFO Waiting for time sync Querying pool.ntp.org ... success (round trip 48 ms) Received time: Sunday, 27-Oct-19 19:02:33.646 UTC Time is in sync
UTC: Sunday, 27-Oct-2019 19:02:33 UTC Timezone lookup for: Europe/London ... (round-trip 61 ms) success. Olson: Europe/London Posix: GMT0BST,M3.5.0/1,M10.5.0 Time in your set timezone: Sunday, 27-Oct-2019 19:02:33 GMT
Looks like the Dublin location is set wrong?
London: Posix: GMT0BST,M3.5.0/1,M10.5.0 Works Dublin: Posix: IST-1GMT0,M10.5.0,M3.5.0/1 Still 1 hour ahead.
Steve
I overlooked that... It does indeed seem as if the database (I just download the one from iana.org) has an error in the entry for Dublin. Even after updating to latest version the problem persists. I have adjusted the entry manually and will report the error upstream. (It surprises me that this is in there, this should affect a huge number of systems...)
My server now correctly responds
$ nc -u timezoned.rop.nl 2342
Europe/Dublin^D
OK Europe/Dublin IST-1GMT0,M3.5.0,M10.5.0/1
If there is no hour to a POSIX time change moment - specified in local time - it defaults to 02:00.
Great - glad I was able to spot and resolve something! Thanks for the update! I'm sure @witnessmenow will also appreciate it. :)
Steve
Still strange that the 'zic' zone info compiler seems to get a wrong POSIX string but the other tools (eg zdump) seem to work. This is all a mess of ancient file formats and arcane time rules... Not even sure how to report this upstream...
OK. now I know more about time in Ireland than I ever wanted to know...
# From Paul Eggert (2017-12-07):
# The 1996 anonymous contributor's goal was to determine the correct
# abbreviation for summer time in Dublin and so the contributor
# focused on the "IST", not on the "Irish Summer Time". Though the
# "IST" was correct, the "Irish Summer Time" appears to have been an
# error, as Ireland's Standard Time (Amendment) Act, 1971 states that
# standard time in Ireland remains at UT +01 and is observed in
# summer, and that Greenwich mean time is observed in winter. (Thanks
# to Derick Rethans for pointing out the error.) That is, when
# Ireland amended the 1968 act that established UT +01 as Irish
# Standard Time, it left standard time unchanged and established GMT
# as a negative daylight saving time in winter. So, in this database
# IST stands for Irish Summer Time for timestamps before 1968, and for
# Irish Standard Time after that. See:
# http://www.irishstatutebook.ie/eli/1971/act/17/enacted/en/print
[...]
# From Paul Eggert (2018-02-15):
# In January 2018 we discovered that the negative SAVE values in the
# Eire rules cause problems with tests for ICU:
# https://mm.icann.org/pipermail/tz/2018-January/025825.html
# and with tests for OpenJDK:
# https://mm.icann.org/pipermail/tz/2018-January/025822.html
#
# To work around this problem, the build procedure can translate the
# following data into two forms, one with negative SAVE values and the
# other form with a traditional approximation for Irish timestamps
# after 1971-10-31 02:00 UTC; although this approximation has tm_isdst
# flags that are reversed, its UTC offsets are correct and this often
# suffices. This source file currently uses only nonnegative SAVE
# values, but this is intended to change and downstream code should
# not rely on it.
In other words: Ireland has a "negative DST in winter" hack in the IANA tz database because they have defined Irish Standard Time (IST) time to apply in summer and GMT in winter. Sigh...
Wow, that's a lot of history! Not to sound like a bad joke - but that is Irish! haha. At least there's reasoning behind it at least!
Oh by the way, feel free to send me a reminder should I forget the manual exception I made if and when Ireland does away with DST altogether...
I have my timezone set to
#define MYTIMEZONE "Europe/Dublin"
And the time should have changed overnight, but it's currently reading 10:30, when it should be 9:30