JRuby provides its own extension for the date library, and this will need to be incorporated into the released gem. We will do the work on this.

They may be ultimate cases, so may not be to fix. But reporting just in case.

require 'date'
puts DateTime._strptime("UTC+99:13", "%z")
puts DateTime._strptime("UTC+99:13:14", "%z")
puts DateTime._strptime("UTC+912:42", "%z")
puts DateTime._strptime("UTC+912:42:49", "%z")
puts DateTime._strptime("UTC-99:13", "%z")
puts DateTime._strptime("UTC-99:13:14", "%z")
puts DateTime._strptime("UTC-912:42", "%z")
puts DateTime._strptime("UTC-912:42:49", "%z")

Until Ruby 3.1 (tested with 2.7.7, 3.0.5, 3.1.3)

{:zone=>"UTC+99:13", :offset=>357180}
{:zone=>"UTC+99:13:14", :offset=>357194}
{:zone=>"UTC+912:42", :offset=>3285720}
{:zone=>"UTC+912:42:49", :offset=>3285769}
{:zone=>"UTC-99:13", :offset=>-357180}
{:zone=>"UTC-99:13:14", :offset=>-357194}
{:zone=>"UTC-912:42", :offset=>-3285720}
{:zone=>"UTC-912:42:49", :offset=>-3285769}

From Ruby 3.2 (tested with Ruby 3.2.1)

{:zone=>"UTC+99:13", :offset=>nil}
{:zone=>"UTC+99:13:14", :offset=>nil}
{:zone=>"UTC+912:42", :offset=>nil}
{:zone=>"UTC+912:42:49", :offset=>nil}
{:zone=>"UTC-99:13", :offset=>nil}
{:zone=>"UTC-99:13:14", :offset=>nil}
{:zone=>"UTC-912:42", :offset=>nil}
{:zone=>"UTC-912:42:49", :offset=>nil}

ruby version: 2.6.5
Code:

$ irb
require 'date'
puts  Date.parse('-1111-2-2').year # => -1111

expected behavior: ruby throws ArgumentError due to invalid string passed
real behavior: negative year returns.

Is it ok?

Previous versions

>> Date._iso8601(nil)
=> {}

3.2.1

>> Date._iso8601(nil)
(irb):2:in `_iso8601': no implicit conversion of nil into String (TypeError)

The Date.commercial method does NOT account for a leap year.

irb(main):099:0> d = Date.parse('2021-01-03')
=> #<Date: 2021-01-03 ((2459218j,0s,0n),+0s,2299161j)>
irb(main):100:0> 
irb(main):101:0> d.year
=> 2021
irb(main):102:0> d.cweek
=> 53
irb(main):103:0> 
irb(main):104:0> 
irb(main):105:0> 
irb(main):106:0> Date.commercial(d.year,d.cweek)
Traceback (most recent call last):
        3: from /usr/bin/irb:11:in `<main>'
        2: from (irb):106
        1: from (irb):106:in `commercial'
ArgumentError (invalid date)
irb(main):107:0>

This expectation started to fail after I installed this gem v.3.3.3

# order.purchased_at = Sun, 26 Jan 0020 00:00:00 UTC +00:00
# order.purchased_at.class == ActiveSupport::TimeWithZone
expect(order.purchased_at).to eq 'Sun, 26 Jan 0020 00:00:00 UTC +00:00'.to_datetime

If I remove this gem the expectation passes

(Sorry, I've reported this in https://bugs.ruby-lang.org/issues/19552, but I found ruby/date would be more appropriate.)

puts Time.now.utc.strftime("%-:::z")

Until Ruby 3.0 (tested with 2.7.7 and 3.0.5) :

+00

From Ruby 3.1 (tested with 3.1.3 and 3.2.1)

-00

On GHSA-qg54-694p-wgpp, it says:

Affected versions
>= 3.2.0, < 3.2.1
>= 3.1.0, < 3.1.2
>= 3.0.0, < 3.0.2
< 2.0.1
Patched versions
3.2.1
3.1.2
3.0.2
2.01

But obviously 2.01 is not a correct version, it should 2.0.1.

And the suggested remediation is then also buggy:

Remediation

Upgrade date to version 2.01 or later. For example:

gem "date", ">= 2.01"

using ruby 2.7.0

Expected:

Date.jd 2459014.5
#<Date: 2020-06-14 ((2459014j,0s,0n),+0s,2299161j)>

DateTime.jd 2459014.5
=> #<DateTime: 2020-06-14T00:00:00+00:00 ((2459014j,0s,0n),+0s,2299161j)>

Actual:

Date.jd 2459014.5
=> #<Date: 2020-06-13 ((2459014j,43200s,0n),+0s,2299161j)>

DateTime.jd 2459014.5
=> #<DateTime: 2020-06-13T12:00:00+00:00 ((2459014j,43200s,0n),+0s,2299161j)>

Problem seems to be that Julian dates should start from noon UTC, which is not the current behaviour.

Hi there,

I'm not sure this is the right place to put such issue, but I found an issue after updating from 3.0.1 to 3.3.3.

I tracked the change in behaviour to start appearing between versions 3.2.2 and 3.3.0, here's and example of the change:

with version 3.2.2

require "time" 
require "date"

Time.parse("1000-01-01T00:00:00Z")
# date v3.2.2 => "1000-01-01T00:00:00.000Z"

Time.parse("1000-01-01T00:00:00Z").to_date
# date v3.2.2 => Wed, 27 Dec 0999

Date.parse("1000-01-01") == Time.parse("1000-01-01T00:00:00Z")
# date v3.2.2 => true

Time.parse("1000-01-01T00:00:00Z") == Date.parse("1000-01-01")
# date v3.2.2 => true

with version 3.3.0

require "time" 
require "date"

Time.parse("1000-01-01T00:00:00Z")
# date v3.3.3 => "1000-01-01T00:00:00.000Z"

Time.parse("1000-01-01T00:00:00Z").to_date
# date v3.3.0 => Wed, 27 Dec 0999

Date.parse("1000-01-01") == Time.parse("1000-01-01T00:00:00Z")
# date v3.3.3 => false

Time.parse("1000-01-01T00:00:00Z") == Date.parse("1000-01-01")
# date v3.3.3 => false

As you can see I'm working with date in the Julian calendar and comparing them used to work before 3.3.0.

Now I'm not sure if and what is the bug there, as this was maybe already an issue:

Time.parse("1000-01-01T00:00:00Z").to_date
# => Wed, 27 Dec 0999

But in the end, this change of behaviour surfaced and I wanted to be sure it's reported.

According to https://rubygems.org/gems/date, 'date' supported ruby version was >=2.4.
However date_core.c refers RB_WARN_CATEGORY_DEPRECATED introduced by Ruby 3.
I wonder if you could check RB_WARN_* in the build process or #Ifndef or anything.
Thanks.

after an upgrade from Ruby 2.5 to Ruby 2.7.1 we are confronted with the following problem:

  def test_marshall
    hexdump = "0408553a09446174655b0b690069006902c0a8553a0d526174696f6e616c5b076c2b0800001a71180269029dff6900660c32323939313631"
    ODBA::Marshal.load(hexdump)
    @group.instance_eval('@logs = {Time.local(2011,2,3) => "value"}')
    assert_equal([2011], @group.years)
  end

Looking at the source code of ruby 2.7.1 I find the string cannot load complex into simple in ext/date/date_core.c. Therefore I think it a problem when restoring a date object.

Question: What exactly changed between Ruby 2.5.0 and 2.7.1 in regards to Marshal.load(hexdump)?

There seems to be subtle change in the marshaling/unmarshalling of the date format between Ruby 2.5.0 and 2.7.1

Loading logs with a marshalled dump done with Ruby 2.5.0 will not load with Ruby 2.7.1. ;(

the last release for this gem was in 2017, when ruby 2.5 was released. Since then, a few changes have been made in 2018 and released in 2.6. But there has not been a new release of the gem.

It would be 💯 if a new release can be organised to release the new changes.

Hello,
currently i cant update some gems, because i get this error:

date_core.c:2980:57: error: 'RUBY_TYPED_FROZEN_SHAREABLE' undeclared here (not in a function)
2980 | RUBY_TYPED_FREE_IMMEDIATELY|RUBY_TYPED_WB_PROTECTED|RUBY_TYPED_FROZEN_SHAREABLE,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:245: date_core.o] Error 1

I update as user, not as root.
Complete output from "LANG=C gem update --debug --verbose --backtrace 2>&1 | tee output.txt"
output.txt

Reference to: https://bugs.ruby-lang.org/issues/17022

What if we have a method Kernel#Date that delegates to Date.parse or Date.iso8601 ?

Dates could be written more naturally, right?

Date("2020-01-13") - Date("2019-01-13")

Capitalized methods are defined on the Kernel module to facilitate construction of basic types:

Kernel.methods.grep(/^[A-Z].*/)
#=> [:Rational, :Complex, :URI, :Integer, :Float, :String, :Array, :Hash, :Pathname]

The method BigDecimal is added when the corresponding library is required:

require 'bigdecimal'
Kernel.methods.grep(/^[A-Z].*/)
#=> [:Rational, :Complex, :BigDecimal, :URI, :Integer, :Float, :String, :Array, :Hash, :Pathname]

The proposal is to do the same for Date, when we do require 'date', a method Kernel#Date would be added.