bug in Time.parse?

[siemenbaader]

Hi,

I stumbled across some odd behavior when using Time.parse. Apparently
<=> fails on Time objects generated by Time.parse when the compared

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 Baader

 

[Robert Klemme]

Hi,

I stumbled across some odd behavior when using Time.parse. Apparently
<=> fails on Time objects generated by Time.parse when the compared

=> "1.8.4"

require 'time'
=> true
=> Tue Apr 10 15:42:40 CEST 2007
=> Tue Apr 10 15:42:40 CEST 2007
=> Tue Apr 10 15:42:40 CEST 2007
=> "Tue Apr 10 15:42:40 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:
=> 1176214767.0

Kind regards

robert

 

[Phillip Gawlowski]

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.

 

[siemenbaader]

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

Of course! Thanks!

- Siemen