Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dublin offset changed between 1.2018.4 and 1.2018.5 #95

Closed
samstickland opened this issue Oct 18, 2018 · 6 comments
Closed

Dublin offset changed between 1.2018.4 and 1.2018.5 #95

samstickland opened this issue Oct 18, 2018 · 6 comments

Comments

@samstickland
Copy link

Using tzinfo-data 1.2018.4

> require 'tzinfo/data'
> TZInfo::Timezone.get('Europe/Dublin').current_period.utc_offset
=> 0

using tzinfo-data 1.2018.5

> require 'tzinfo/data'
> TZInfo::Timezone.get('Europe/Dublin').current_period.utc_offset
=> 3600

Of course, the offset in Dublin hasn't changed!

@samstickland
Copy link
Author

samstickland commented Oct 18, 2018

I found the issue. 2018f uses a negative offset for Irish Winter Time, whereas earlier versions used a positive offset for "Irish Summer Time" (which doesn't actually exist). Technically the negative offset for Irish Winter Time is correct.

@thomasbalsloev
Copy link

@samstickland

How is this not still an issue?
As I read your comment the base offset for Dublin is now 3600 seconds instead of 0.

2.6.2 :051 > t = TZInfo::Timezone.get('Europe/Dublin')
 => #<TZInfo::DataTimezone: Europe/Dublin> 
2.6.2 :052 > t.current_period.utc_offset
 => 3600 
2.6.2 :053 > t.current_period.std_offset
 => 0

From what I can read in the code method "utc_offset" should return the base offset, i.e. 0 for this zone regardless of the time of year.
Comment from the code: "The base offset of the timezone from UTC in seconds. This does not include any adjustment made for daylight savings time and will typically remain constant throughout the year."

Method "std_offset" should return the difference in seconds between the current period offset relative to the base offset.
Comment from the code: "The offset from the time zone's standard time in seconds. Zero when daylight savings time is not in effect. Non-zero (usually 3600 = 1 hour) if daylight savings is being observed."

The numbers I get are thus just plain wrong. This is a bug in my view.

I use TZinfo version 1.2.5.
Rails 5.1.6.7.
Ruby 2.6.2.

@thomasbalsloev
Copy link

@philr

Any thoughts on this?

@samstickland
Copy link
Author

samstickland commented Apr 3, 2019

@P9GIT Ireland is 3600 offset from UTC, and they don't have summer daylight saving.

Instead in winter they subtract 3600 seconds. This is exceedingly rare, and I hadn't come across this before: https://en.wikipedia.org/wiki/Winter_time_(clock_lag)

The upshot of this is that the time in Ireland is identical the time in the UK, but the base offsets are different. The UK is UTC + 0, and they add 3600 during summer. Ireland is UTC + 3600, and they subtract 3600 during winter.

@philr
Copy link
Member

philr commented Apr 3, 2019

@P9GIT @samstickland is correct, Europe/Dublin applies negative daylight savings in the winter. This isn't a bug. utc_offset is constant at 3600 seconds throughout the year. std_offset is -3600 in winter and 0 in summer:

t = TZInfo::Timezone.get('Europe/Dublin')

winter = t.period_for(Time.utc(2019, 1, 1))
winter.utc_offset
# => 3600
winter.std_offset
# => -3600
winter.dst?
# => true

summer = t.period_for_utc(Time.utc(2019, 7, 1))
summer.utc_offset
# => 3600
summer.std_offset
# => 0
summer.dst?
# => false

The commentary regarding Ireland in the IANA Time Zone Database states the following on the matter:

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. ... 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.

@thomasbalsloev
Copy link

@samstickland @philr

I see. Weird that they chose to be "different" from the normal DST procedure...

Thanks for the explanation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants