Forum: Ruby bug in Time.parse?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2007-04-10 18:06
(Received via mailing list)
Hi,

I stumbled across some odd behavior when using Time.parse. Apparently
<=> fails on Time objects generated by Time.parse when the compared
objects are equal. The parsed object appears smaller to <=>.

> VERSION
=> "1.8.4"

require 'time'
=> true
> t = Time.now
=> Tue Apr 10 15:42:40 CEST 2007
> tt = t.dup
=> Tue Apr 10 15:42:40 CEST 2007
> t == tt
=> true
> tt =Time.parse(t.to_s)
=> Tue Apr 10 15:42:40 CEST 2007
> t == tt
=> false
> tt < t
=> true
> t.to_s
=> "Tue Apr 10 15:42:40 CEST 2007"
> t == Time.parse("Tue Apr 10 15:42:40 CEST 2007")
=> false
> t > Time.parse("Tue Apr 10 15:42:40 CEST 2007")
=> true
> t > Time.parse("Tue Apr 10 15:42:41 CEST 2007")
=> false
> t < Time.parse("Tue Apr 10 15:42:41 CEST 2007")
=> true
> t > Time.parse("Tue Apr 10 15:42:39 CEST 2007")
=> true

As Time#inspect is overridden i don't know how to examine if there are
any differences  between the objects created with parse and dup
respectively...

Is this known? Is it a bug or do I misunderstand something?

I could not find it mentioned in the bugtracker or on the 'net with
google.

- Siemen B.
Robert K. (Guest)
on 2007-04-10 18:25
(Received via mailing list)
On 10.04.2007 16:03, removed_email_address@domain.invalid wrote:
> => true
>> tt < t
> => true
>> t > Time.parse("Tue Apr 10 15:42:39 CEST 2007")
> => true
>
> As Time#inspect is overridden i don't know how to examine if there are
> any differences  between the objects created with parse and dup
> respectively...
>
> Is this known? Is it a bug or do I misunderstand something?

This is not a bug.  Time.parse can only parse what it gets to see:

 >> require 'time'
=> true
 >> t=Time.now
=> Tue Apr 10 16:19:27 +0200 2007
 >> t.to_s
=> "Tue Apr 10 16:19:27 +0200 2007"
 >> tt=Time.parse(t.to_s)
=> Tue Apr 10 16:19:27 +0200 2007
 >> t.to_s
=> "Tue Apr 10 16:19:27 +0200 2007"
 >> tt.to_s
=> "Tue Apr 10 16:19:27 +0200 2007"
 >> tt - t
=> -0.125357
 >> t.to_f
=> 1176214767.12536
 >> tt.to_f
=> 1176214767.0

Kind regards

  robert
Phillip G. (Guest)
on 2007-04-10 18:29
(Received via mailing list)
removed_email_address@domain.invalid wrote:

> I stumbled across some odd behavior when using Time.parse. Apparently
> <=> fails on Time objects generated by Time.parse when the compared
> objects are equal. The parsed object appears smaller to <=>.
>
>
> Is this known? Is it a bug or do I misunderstand something?
>
> I could not find it mentioned in the bugtracker or on the 'net with
> google.

http://www.ruby-doc.org/core/classes/Time.html#M000249

Looking into the Ruby documentation, I see a note regarding resolution:
Time.now may be off by fractions of seconds, depending on your computer.

For example, *nixes calculate the time using January 1st 1970 as
starting point, and calculate the seconds passed since then (IIRC).
Windows probably uses the CMOS clock on the motherboard, which can be
off by a few seconds (or there's latency when using NTP to sync times
with a clock..)

AFAIK, this is a similar debate to random vs pseudo-random ;)

--
Phillip "CynicalRyan" Gawlowski
http://cynicalryan.110mb.com/

Rule of Open-Source Programming #15:

If you like it, let the author know. If you hate it, let the author
know why.
unknown (Guest)
on 2007-04-10 18:36
(Received via mailing list)
>
> This is not a bug.  Time.parse can only parse what it gets to see:

Of course! Thanks!

- Siemen
This topic is locked and can not be replied to.