[#98621] Re: Function getlogin_r()'s protoype] — Bertram Scharpf <lists@...>
FYI,
3 messages
2020/06/02
[#98947] [Ruby master Feature#16986] Anonymous Struct literal — ko1@...
Issue #16986 has been reported by ko1 (Koichi Sasada).
66 messages
2020/06/26
[#98962] [Ruby master Bug#16988] Kernel.load loads file from current directory without '.' in path — misharinn@...
Issue #16988 has been reported by TheSmartnik (Nikita Misharin).
5 messages
2020/06/26
[#98969] [Ruby master Feature#16994] Sets: shorthand for frozen sets of symbols / strings — marcandre-ruby-core@...
Issue #16994 has been reported by marcandre (Marc-Andre Lafortune).
7 messages
2020/06/26
[#100117] [Ruby master Feature#16994] Sets: shorthand for frozen sets of symbols / strings
— matz@...
2020/09/25
Issue #16994 has been updated by matz (Yukihiro Matsumoto).
[ruby-core:98894] [Ruby master Feature#16031] Raise ArgumentError when creating Time objects with invalid day of month, instead of rolling into next month
From:
merch-redmine@...
Date:
2020-06-20 04:23:29 UTC
List:
ruby-core #98894
Issue #16031 has been updated by jeremyevans0 (Jeremy Evans).
Dan0042 (Daniel DeLorme) wrote in #note-3:
> It's true that this behavior is due to how Time behaves generally, but I think this is a valid bug report specifically related to strptime. I don't think the OP was really asking for a change in the rollover behavior of Time#local, just that strptime should not behave like that.
>
> As far as I understand the rollover is meant to deal with Time _arithmetic_, so we can change the year/month, and the day will automagically adjust. But for Time _parsing_, if you have the string "2019-02-31" it should fail parsing imho.
I disagree. `Time.parse` and `Time.strptime` should remain consistent with other Time constructors. Either all constructors should be strict and reject the dates, or none of the constructors should. Barring backwards compatibility issues, I think it would be best to make all constructors strict. However, I don't think the benefits of doing so outweigh the backwards compatibility break.
For what its worth, anyone doing time arithmetic at the day/year/month level is better off using Date/DateTime. Date's arithmetic makes more sense, clamping to the end of the month instead of spilling into the next month. It also offers a nicer API.
```ruby
Date.new(2001, 1, 31) >> 1
# => #<Date: 2001-02-28 ((2451969j,0s,0n),+0s,2299161j)>
```
----------------------------------------
Feature #16031: Raise ArgumentError when creating Time objects with invalid day of month, instead of rolling into next month
https://bugs.ruby-lang.org/issues/16031#change-86271
* Author: aliism (Ali Ismayilov)
* Status: Open
* Priority: Normal
----------------------------------------
When parsing an invalid date, like February 31 or November 31, I get different results from Date and Time classes.
``` ruby
require 'date'
require 'time'
Date.strptime('2019-02-31', '%Y-%m-%d')
# Traceback (most recent call last):
# 5: from /Users/ali/.rbenv/versions/2.6.3/bin/irb:23:in `<main>'
# 4: from /Users/ali/.rbenv/versions/2.6.3/bin/irb:23:in `load'
# 3: from /Users/ali/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
# 2: from (irb):5
# 1: from (irb):5:in `strptime'
# ArgumentError (invalid date)
Time.strptime('2019-02-31', '%Y-%m-%d')
# => 2019-03-03 00:00:00 +0100
```
I'd expect Time class to throw ArgumentError, just like the Date class.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>