require 'test/unit'

class DateParseTest < Test::Unit::TestCase
  def test_parse
    #Date returned from WIN32OLE
    Time.parse("20060702160425.000000-300")
  end
end

Date: 2007-11-01 15:20
Sender: Daniel Berger

Dates returned by WMI class members typically use that date format.
This code snippet demonstrates the issue:

require 'win32ole'
require 'socket'

host  = Socket.gethostname
cs    = "winmgmts://#{host}/root/cimv2"
wmi   = WIN32OLE.connect(cs)
query = "select * from Win32_OperatingSystem"

wmi.InstancesOf("Win32_OperatingSystem").each{ |ole|
   p ole.InstallDate
   p ole.LastBootUpTime
   p ole.LocalDateTime
   p Time.parse(ole.InstallDate) # boom!
}

Date: 2007-09-02 04:30
Sender: Shyouhei Urabe

Out of curiosity, tell us how to see that date format using WIN32OLE?
We've not been able to get one so far.

And that 1.8.5 result is broken anyway. 1.8.5 parses yyyymmddhhmmss
part and ignores anything other (this case
".000000-300").

Current 1.8 branch does support this format. But I doubt we should
backport that to older branches.

Date: 2007-07-11 18:41
Sender: Daniel Berger

Upon further review I'm of a mixed mind about this. One the one
hand, it does turn out to be an MS specific date format. On the
other hand, it worked fine in versions of Ruby prior to 1.8.6:

irb(main):001:0> RUBY_VERSION
=> "1.8.5"
irb(main):002:0> Time.parse("20060702160425")
=> Sun Jul 02 16:04:25 -0600 2006
irb(main):003:0> Time.parse("20060702160425.000000-300&qu
ot;)
=> Sun Jul 02 16:04:25 -0600 2006

irb(main):001:0> RUBY_VERSION
=> "1.8.6"
irb(main):002:0> Time.parse("20060702160425")
=> Sun Jul 02 16:04:25 -0600 2006
irb(main):003:0> Time.parse("20060702160425.000000-300&qu
ot;)
RangeError: bignum too big to convert into `long'
        from C:/ruby/lib/ruby/1.8/time.rb:184:in `local'
        from C:/ruby/lib/ruby/1.8/time.rb:184:in `make_time'
        from C:/ruby/lib/ruby/1.8/time.rb:243:in `parse'
        from (irb):3

What happened?

Date: 2007-05-25 19:12
Sender: Daniel Berger

I've had to deal with these before. But, is this an MS-specific
date format? I can't remember.

If it is MS-specific, then this bug should be rejected. Otherwise,
I don't think this would be difficult to support.

Dan