From @masak

<masak> r​: say Date.new(-13_000_000_000, 1, 1)
<p6eval> rakudo cc1858​: OUTPUT«-115098112-01-01␤»
<masak> o.O
<masak> I suppose -115098112 above is a bug?
<masak> r​: say -13_000_000_000
<p6eval> rakudo cc1858​: OUTPUT«-13000000000␤»
* masak submits rakudobug

From 1parrota@gmail.com

<masak> r​: say Date.new(-13_000_000_000, 1, 1)
<p6eval> rakudo cc1858​: OUTPUT«-115098112-01-01␤»

That would hose Perl 6 for any speculations on the age of the Universe. :-)*

The RT System itself - Status changed from 'new' to 'open'

From @coke

On Wed Sep 05 04​:56​:22 2012, masak wrote​:

<masak> r​: say Date.new(-13_000_000_000, 1, 1)
<p6eval> rakudo cc1858​: OUTPUT«-115098112-01-01␤»
<masak> o.O
<masak> I suppose -115098112 above is a bug?
<masak> r​: say -13_000_000_000
<p6eval> rakudo cc1858​: OUTPUT«-13000000000␤»
* masak submits rakudobug

This seems consistent with trying to use a value that is too big for an Int (which $.year is); are
you arguing that this should throw an error, that an Int $.year should autopromote to something
else, or that $.year should be declared as something else?

--
Will "Coke" Coleda

From @masak

masak (>>), coke (>)​:

<masak> r​: say Date.new(-13_000_000_000, 1, 1)
<p6eval> rakudo cc1858​: OUTPUT«-115098112-01-01␤»
<masak> o.O
<masak> I suppose -115098112 above is a bug?
<masak> r​: say -13_000_000_000
<p6eval> rakudo cc1858​: OUTPUT«-13000000000␤»
* masak submits rakudobug

This seems consistent with trying to use a value that is too big for
an Int (which $.year is); are
you arguing that this should throw an error, that an Int $.year should
autopromote to something
else, or that $.year should be declared as something else?

Either of those three would solve the real issue here, which (IMO) is
that something different comes out than was put in. Generally, it's not
nice to destroy user data without at least giving a warning that
significant digits were lost.

I have no opinion in which of the three methods is preferable, though.
Maybe this, too, should be a spec issue.

From @pmichaud

On Thu, May 30, 2013 at 03​:12​:02AM -0700, Carl Mäsak via RT wrote​:

masak (>>), coke (>)​:

<masak> r​: say Date.new(-13_000_000_000, 1, 1)
<p6eval> rakudo cc1858​: OUTPUT«-115098112-01-01␤»
<masak> o.O
<masak> I suppose -115098112 above is a bug?

This seems consistent with trying to use a value that is too big for
an Int (which $.year is); are
you arguing that this should throw an error, that an Int $.year should
autopromote to something
else, or that $.year should be declared as something else?

How is it possible for a value to be "too big for an Int"? Could this
be rephrased or re-analyzed somehow?

Pm

From @coke

I was trying to imply that it was an overflow error.

On Thu, May 30, 2013 at 11​:09 AM, Patrick R. Michaud <pmichaud@​pobox.com>wrote​:

On Thu, May 30, 2013 at 03​:12​:02AM -0700, Carl Mäsak via RT wrote​:

masak (>>), coke (>)​:

<masak> r​: say Date.new(-13_000_000_000, 1, 1)
<p6eval> rakudo cc1858​: OUTPUT«-115098112-01-01␤»
<masak> o.O
<masak> I suppose -115098112 above is a bug?

This seems consistent with trying to use a value that is too big for
an Int (which $.year is); are
you arguing that this should throw an error, that an Int $.year should
autopromote to something
else, or that $.year should be declared as something else?

How is it possible for a value to be "too big for an Int"? Could this
be rephrased or re-analyzed somehow?

Pm

--
Will "Coke" Coleda

From @pmichaud

On Thu, May 30, 2013 at 11​:54​:30AM -0400, Will Coleda wrote​:

I was trying to imply that it was an overflow error.

Okay. I suspect the overflow is not because of the Int, but because
of the use of sprintf() in the date/time formatting routines, which
doesn't handle large integers properly. See also RT #​118253.

Switching the formatter to (temporarily?) use %s instead of %d might
resolve the problem, as stringification of large ints works fine.

Pm

From @FROGGS

Fixed, tests are at Raku/roast@2647c16652

@FROGGS - Status changed from 'open' to 'resolved'