Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Time.gm(1969) chokes on Windows

Reply
Thread Tools

Time.gm(1969) chokes on Windows

 
 
Thibaut Barrère
Guest
Posts: n/a
 
      01-06-2008
> I am left with no choice BUT to work around
> Syck's (IMO shortsighted) choice of using Time.gm rather than DateTime,
> which I'm fairly certain was done for performance reasons...


I find it unfortunate to still see a difference of behaviour for the
Time class, depending on your runtime platform. I don't expect each
library developer to actually care for that personally.

I have been littl'bitten (caught it thanks to unit tests a while
back and was kind of disappointed to discover this !

Does anyone know if there are plans to make Time behaviour
'homogeneous' ? (like: fixing the Windows version maybe ?)

cheers

Thibaut
--
LoGeek
[blog] http://evolvingworker.com - tools for a better day
[blog] http://blog.logeek.fr - about writing software
 
Reply With Quote
 
 
 
 
James Tucker
Guest
Posts: n/a
 
      01-06-2008

On 6 Jan 2008, at 11:20, Thibaut Barr=E8re wrote:

>> I am left with no choice BUT to work around
>> Syck's (IMO shortsighted) choice of using Time.gm rather than =20
>> DateTime,
>> which I'm fairly certain was done for performance reasons...

>
> I find it unfortunate to still see a difference of behaviour for the
> Time class, depending on your runtime platform. I don't expect each
> library developer to actually care for that personally.
>
> I have been littl'bitten (caught it thanks to unit tests a while
> back and was kind of disappointed to discover this !
>
> Does anyone know if there are plans to make Time behaviour
> 'homogeneous' ? (like: fixing the Windows version maybe ?)


Well, the bug tracker would be a good place to start

>
>
> cheers
>
> Thibaut
> --
> LoGeek
> [blog] h



 
Reply With Quote
 
 
 
 
Ryan Davis
Guest
Posts: n/a
 
      01-06-2008

On Jan 4, 2008, at 07:24 , Tim Ferrell wrote:

> Obviously the string in question is a timestamp - YAML/Syck handles
> plain pre-1970 dates just fine. So, assuming I have valid pre-1970
> timestamps to deal with, I am left with no choice BUT to work around
> Syck's (IMO shortsighted) choice of using Time.gm rather than
> DateTime,
> which I'm fairly certain was done for performance reasons... Still, it
> seems a rather bad choice given that it is not always portable.


I'm gonna have to call bullshit on this one, given that you were asked
twice to provide the bad YAML in question and it never materialized,
but especially given that the following seems to work just fine:

>> YAML.dump(Time.gm(1969, 1, 1))

=> "--- 1969-01-01 00:00:00 Z\n"
>> YAML.load(YAML.dump(Time.gm(1969, 1, 1)))

=> Wed Jan 01 00:00:00 UTC 1969


 
Reply With Quote
 
Jamey Cribbs
Guest
Posts: n/a
 
      01-06-2008
[Note: parts of this message were removed to make it a legal post.]

Ryan, was this on a non-Windows device? IIRC, it is not Ruby or YAML that
is the culprit, but the underlying OS library that Ruby's Time class uses.
The OS library works fine on Unix-based platforms. It is only the
underlying Windows library that has an issue with times prior to 1970.

But you are correct, Tim can bitch as long as he wants about Syck's
shortsitedness, but he should really be bitching that the underlying Windows
library can't handle pre-1970 times.

Jamey


On Jan 6, 2008 2:16 PM, Ryan Davis <(E-Mail Removed)> wrote:

>
> On Jan 4, 2008, at 07:24 , Tim Ferrell wrote:
>
> > Obviously the string in question is a timestamp - YAML/Syck handles
> > plain pre-1970 dates just fine. So, assuming I have valid pre-1970
> > timestamps to deal with, I am left with no choice BUT to work around
> > Syck's (IMO shortsighted) choice of using Time.gm rather than
> > DateTime,
> > which I'm fairly certain was done for performance reasons... Still, it
> > seems a rather bad choice given that it is not always portable.

>
> I'm gonna have to call bullshit on this one, given that you were asked
> twice to provide the bad YAML in question and it never materialized,
> but especially given that the following seems to work just fine:
>
> >> YAML.dump(Time.gm(1969, 1, 1))

> => "--- 1969-01-01 00:00:00 Z\n"
> >> YAML.load(YAML.dump(Time.gm(1969, 1, 1)))

> => Wed Jan 01 00:00:00 UTC 1969
>
>
>
>


 
Reply With Quote
 
Tim Ferrell
Guest
Posts: n/a
 
      01-06-2008
Ryan Davis wrote:
>
> I'm gonna have to call bullshit on this one, given that you were asked
> twice to provide the bad YAML in question and it never materialized,
> but especially given that the following seems to work just fine:
>
> >> YAML.dump(Time.gm(1969, 1, 1))

> => "--- 1969-01-01 00:00:00 Z\n"
> >> YAML.load(YAML.dump(Time.gm(1969, 1, 1)))

> => Wed Jan 01 00:00:00 UTC 1969


Ryan, you obviously didn't follow closely enough... That code simply
does not work on Windows.

>> YAML.dump(Time.gm(1969, 1, 1))

ArgumentError: time out of range
from (irb):2:in 'gm'
from (irb):2

Nor does this:

>> Yaml.load("--- 1969-01-01 00:00:00 Z")

ArgumentError: time out of range
from C:/Ruby/lib/ruby/1.8/yaml/rb:133:in 'utc'
from C:/Ruby/lib/ruby/1.8/yaml/rb:133:in 'node_import'
from C:/Ruby/lib/ruby/1.8/yaml/rb:133:in 'load'
from C:/Ruby/lib/ruby/1.8/yaml/rb:133:in 'load'
from (irb):3

And yes, Jamey, it is not Syck's fault that the Time class is broken in
this way on Windows. Syck could have alleviated some of the pain by
making the more sensible (i.e. portable, reliable) choice of using
DateTime to deserialize, but the bottom line IMO is that this is a core
issue and should be fixed.

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Tim Ferrell
Guest
Posts: n/a
 
      01-06-2008

FWIW, I filed a bug report on this:

http://rubyforge.org/tracker/index.p...=426&atid=1698

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Tim Ferrell
Guest
Posts: n/a
 
      01-07-2008
Yukihiro Matsumoto wrote:
> Hi,
> As many pointed out, Windows time library (probably intentionally)
> does not support pre-1970 time. Until Microsoft fixes the bug (or
> spec), we can't help it. The alternative is implementing our own time
> handling functions but I don't think we have enough resource.
>
> matz.


Hello matz - I do understand both sides of this - Window is "broken" in
this respect and working around it is (pardon the pun) time consuming...

It would be helpful, at least, to have Syck fall back to using DateTime
when Time.gm fails though... this is what the Rails core extensions in
ActiveSupport do to work around the overflow...

Cheers,
Tim
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Windows chokes on latest Microsoft patch Imhotep Computer Security 0 10-19-2005 04:09 AM
Explorer.exe chokes CPU 100% during 2 mins from startup Maria Computer Support 3 04-17-2005 04:07 PM
deepcopy chokes with TypeError on dynamically assigned instance method ‘5ÛHH575-UAZWKVVP-7H2H48V3 Python 7 02-15-2005 08:17 AM
New compiler chokes on template class William Payne C++ 3 08-22-2004 09:48 PM
Norton Antispam Chokes Outlook Express SNTP Computer Support 5 02-10-2004 04:21 AM



Advertisments