Bug #10767: Time.local doesn't raise an exception during the dead hour on DST

• Status: Rejected
• Assignee: akr (Akira Tanaka)
• Target version: -
• ruby -v: ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux-gnu]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[sobrinho (Gabriel Sobrinho)]

At the begin of DST ruby is accepting the 0 hour which in fact doesn't exists:

Time.local(2014, 10, 19, 0, 30)
#=> 2014-10-19 01:30:00 -0200

Time.local(2014, 10, 19, 1, 30)
#=> 2014-10-19 01:30:00 -0200

Time.local(2014, 10, 19, 2, 30)
#=> 2014-10-19 02:30:00 -0200

In fact it is returning the next hour for some reason, causing a really strange behaviour:

Time.local(2014, 10, 19, 0, 30) == Time.local(2014, 10, 19, 1, 30)
#=> true

I think it makes more sense to raise an exception as happens when you specify a invalid month, day, hour, minute or second:

Time.local(2014, 10, 19, 1, 60) # 60 minutes doesn't exists
ArgumentError: invalid date

Time.local(2014, 10, 19, 25, 30) # 25 hours doesn't exists
ArgumentError: invalid date

Makes sense? I would be happy to provide a patch.

[akr (Akira Tanaka)]

• Related to Bug #10588: Invalid Dates added

[akr (Akira Tanaka)]

• Status changed from Open to Rejected

Sometimes an application needs a time object near the given arguments even if the time object doesn't represent the arguments exactly.
It is especially useful for DST and leap second because an application cannot expect DST and leap second (unless the application contains complete timezone database).
Your proposal makes the methods useless for this needs.

If an application want to test the argument represent a time which is not exist, it can compare obtained time object and the arguments.

So this proposal makes methods less useful.

Actually, I tried the round trip test once.
(ruby-core:14517, ruby-dev:33058, r14765, r15203)
But it caused troubles than benefits.

[akr (Akira Tanaka)]

• Assignee set to akr (Akira Tanaka)