Time.gm(1969) chokes on Windows

Discussion in 'Ruby' started by Tim Ferrell, Jan 3, 2008.

  1. Tim Ferrell

    Tim Ferrell Guest

    I was trying to sort out a YAML parsing issue on Windows XP SP 2 and
    traced it to Time.gm failing on pre-1970 dates ... this works fine on
    both Ubuntu Linux and my Mac... Any ideas or workarounds?

    Thanks!
    Tim
    --
    Posted via http://www.ruby-forum.com/.
     
    Tim Ferrell, Jan 3, 2008
    #1
    1. Advertising

  2. Tim Ferrell

    James Tucker Guest

    It may or may not be related, but check in:

    Control Panel -> Regional and Language Options -> Regional Options ->
    Customize... -> Date -> "Calendar"

    You'll find the default time ranges for date assumptions.

    It's quite likely that ruby doesn't use these though.

    On 3 Jan 2008, at 14:12, Tim Ferrell wrote:

    >
    > I was trying to sort out a YAML parsing issue on Windows XP SP 2 and
    > traced it to Time.gm failing on pre-1970 dates ... this works fine on
    > both Ubuntu Linux and my Mac... Any ideas or workarounds?
    >
    > Thanks!
    > Tim
    > --
    > Posted via http://www.ruby-forum.com/.
    >
     
    James Tucker, Jan 3, 2008
    #2
    1. Advertising

  3. If you want a date, use Date. (require 'date')

    It handled any date you'd care to throw at it and 1969/1970 is not an
    issue.

    -Rob

    On Jan 3, 2008, at 1:20 PM, James Tucker wrote:

    > It may or may not be related, but check in:
    >
    > Control Panel -> Regional and Language Options -> Regional Options -
    > > Customize... -> Date -> "Calendar"

    >
    > You'll find the default time ranges for date assumptions.
    >
    > It's quite likely that ruby doesn't use these though.
    >
    > On 3 Jan 2008, at 14:12, Tim Ferrell wrote:
    >
    >>
    >> I was trying to sort out a YAML parsing issue on Windows XP SP 2 and
    >> traced it to Time.gm failing on pre-1970 dates ... this works fine on
    >> both Ubuntu Linux and my Mac... Any ideas or workarounds?
    >>
    >> Thanks!
    >> Tim



    Rob Biedenharn http://agileconsultingllc.com
     
    Rob Biedenharn, Jan 3, 2008
    #3
  4. Tim Ferrell

    David Morton Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    I'd expect it to be the other way around, when using Time as opposed
    to Date:

    http://en.wikipedia.org/wiki/Unix_time


    On Jan 3, 2008, at 12:12 PM, Tim Ferrell wrote:

    >
    > I was trying to sort out a YAML parsing issue on Windows XP SP 2 and
    > traced it to Time.gm failing on pre-1970 dates ... this works fine on
    > both Ubuntu Linux and my Mac... Any ideas or workarounds?
    >
    > Thanks!
    > Tim
    > --
    > Posted via http://www.ruby-forum.com/.
    >


    David Morton
    Maia Mailguard http://www.maiamailguard.com




    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)

    iD8DBQFHfSypUy30ODPkzl0RAibiAKCxj51ItJR2UZlURyubdZY0cUpT7ACgx7FQ
    djOCSDn7tHIUIVIjGhOc4oU=
    =a1gl
    -----END PGP SIGNATURE-----
     
    David Morton, Jan 3, 2008
    #4
  5. Tim Ferrell

    Tim Ferrell Guest

    Thanks Rob, but unfortunately I am not the one doing the parsing - YAML
    is... and it uses Time.gm/Time.utc, which are apparently "built-in"
    functions in Ruby (i.e. implemented in C) ... I can't help but think
    this is just a setting somewhere...

    I checked my regional settings (as James Tucker suggested) but that
    setting only appears to affect how Windows interprets 2-digit years.
    Ruby must be doing some kind of system api call for this and it is just
    limited on Windows...

    Any other thoughts?


    Rob Biedenharn wrote:
    > If you want a date, use Date. (require 'date')
    >
    > It handled any date you'd care to throw at it and 1969/1970 is not an
    > issue.

    --
    Posted via http://www.ruby-forum.com/.
     
    Tim Ferrell, Jan 3, 2008
    #5
  6. On Jan 3, 2008, at 2:29 PM, Tim Ferrell wrote:
    > Thanks Rob, but unfortunately I am not the one doing the parsing -
    > YAML
    > is... and it uses Time.gm/Time.utc, which are apparently "built-in"
    > functions in Ruby (i.e. implemented in C) ... I can't help but think
    > this is just a setting somewhere...
    >
    > I checked my regional settings (as James Tucker suggested) but that
    > setting only appears to affect how Windows interprets 2-digit years.
    > Ruby must be doing some kind of system api call for this and it is
    > just
    > limited on Windows...
    >
    > Any other thoughts?


    irb> YAML.load("--- 2008-01-03 14:42:18.998097 -05:00\n").class
    => Time
    irb> YAML.load("--- 2008-01-03\n").class
    => Date

    What does your YAML look like? What exactly is being parsed (and
    where does it come from if that might matter)?

    -Rob

    > Rob Biedenharn wrote:
    >> If you want a date, use Date. (require 'date')
    >>
    >> It handled any date you'd care to throw at it and 1969/1970 is not an
    >> issue.

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


    Rob Biedenharn http://agileconsultingllc.com
     
    Rob Biedenharn, Jan 3, 2008
    #6
  7. Tim Ferrell

    Jamey Cribbs Guest

    [Note: parts of this message were removed to make it a legal post.]

    Nope. It's not going to work on windows. You can always force the value in
    the YAML file to be a string by prepending it with !str, and then you can
    convert it however you want in your script.



    On Jan 3, 2008 2:29 PM, Tim Ferrell < > wrote:

    >
    > Thanks Rob, but unfortunately I am not the one doing the parsing - YAML
    > is... and it uses Time.gm/Time.utc, which are apparently "built-in"
    > functions in Ruby (i.e. implemented in C) ... I can't help but think
    > this is just a setting somewhere...
    >
    > I checked my regional settings (as James Tucker suggested) but that
    > setting only appears to affect how Windows interprets 2-digit years.
    > Ruby must be doing some kind of system api call for this and it is just
    > limited on Windows...
    >
    > Any other thoughts?
    >
    >
    > Rob Biedenharn wrote:
    > > If you want a date, use Date. (require 'date')
    > >
    > > It handled any date you'd care to throw at it and 1969/1970 is not an
    > > issue.

    > --
    > Posted via http://www.ruby-forum.com/.
    >
    >
    >
     
    Jamey Cribbs, Jan 3, 2008
    #7
  8. Tim Ferrell

    Tim Ferrell Guest

    Jamey Cribbs wrote:
    > Nope. It's not going to work on windows. You can always force the
    > value in
    > the YAML file to be a string by prepending it with !str, and then you
    > can
    > convert it however you want in your script.


    Well, in this case I have no control over how the yaml file gets
    created...

    This just seems to me to be a bad design decision somewhere. Why would
    YAML use Time.gm to deserialize rather than DateTime given the fact that
    Time.gm behavior is so system-dependent?!

    What I ended up doing to work around this temporarily was get a hold of
    the pure ruby yaml library, RbYAML, and hacked the timestamp code to use
    DateTime.parse instead of Time.gm - I haven't finished fully testing it
    yet and I may be missing some kind of big issue as well, but it seems to
    work at the moment.

    This, in concert with the Rails ActiveSupport Date/Time/DateTime core
    extensions gives me some ability to work with timestamps in a fairly
    interchangeable fashion but... honestly, this kind of thing sucks!
    Having two seemingly similar timestamp classes just leads to confusion,
    especially with those new to the language! The fact that their APIs
    aren't similar doesn't help matters, as that must end up dictating which
    to use in some cases... IMO, DateTime and Time objects should be fully
    interchangeable!
    --
    Posted via http://www.ruby-forum.com/.
     
    Tim Ferrell, Jan 4, 2008
    #8
  9. On Jan 4, 2008, at 8:03 AM, Tim Ferrell wrote:
    > Jamey Cribbs wrote:
    >> Nope. It's not going to work on windows. You can always force the
    >> value in
    >> the YAML file to be a string by prepending it with !str, and then you
    >> can
    >> convert it however you want in your script.

    >
    > Well, in this case I have no control over how the yaml file gets
    > created...



    You still haven't shown the exact format of the string that YAML
    doesn't parse the way you want. I showed you that the format of the
    string influences whether YAML creates a Date or a Time object. If
    you have a string that appears to be in the format of a time, but is
    outside the range of a Time object (on your platform), there may not
    be any way to get YAML to do what you want. You can either get a
    better platform or preprocess the YAML to add the type specifier !str
    as Jamey suggests. (Or perhaps some other hackery to change how YAML
    treats timestamps on your platform.)

    -Rob

    Rob Biedenharn http://agileconsultingllc.com
     
    Rob Biedenharn, Jan 4, 2008
    #9
  10. Tim Ferrell

    Tim Ferrell Guest

    Rob Biedenharn wrote:
    >
    > You still haven't shown the exact format of the string that YAML
    > doesn't parse the way you want. I showed you that the format of the
    > string influences whether YAML creates a Date or a Time object. If
    > you have a string that appears to be in the format of a time, but is
    > outside the range of a Time object (on your platform), there may not
    > be any way to get YAML to do what you want. You can either get a
    > better platform or preprocess the YAML to add the type specifier !str
    > as Jamey suggests.


    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.

    My workaround was to drop Syck for this app and use a customized version
    of RbYAML, as mentioned in my previous post.

    As for the "better platform" comment - believe me, it is not my choice
    to use Windows for this particular case but, given some constraints I am
    in no position to address right now, there is no other option.
    --
    Posted via http://www.ruby-forum.com/.
     
    Tim Ferrell, Jan 4, 2008
    #10
  11. > 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
     
    Thibaut Barrère, Jan 6, 2008
    #11
  12. Tim Ferrell

    James Tucker Guest

    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
     
    James Tucker, Jan 6, 2008
    #12
  13. Tim Ferrell

    Ryan Davis Guest

    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
     
    Ryan Davis, Jan 6, 2008
    #13
  14. Tim Ferrell

    Jamey Cribbs Guest

    [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 <> 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
    >
    >
    >
    >
     
    Jamey Cribbs, Jan 6, 2008
    #14
  15. Tim Ferrell

    Tim Ferrell Guest

    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/.
     
    Tim Ferrell, Jan 6, 2008
    #15
  16. Tim Ferrell

    Tim Ferrell Guest

    Tim Ferrell, Jan 6, 2008
    #16
  17. Tim Ferrell

    Tim Ferrell Guest

    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/.
     
    Tim Ferrell, Jan 7, 2008
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. William Payne

    New compiler chokes on template class

    William Payne, Aug 21, 2004, in forum: C++
    Replies:
    3
    Views:
    390
    Old Wolf
    Aug 22, 2004
  2. ‘5ÛHH575-UAZWKVVP-7H2H48V3
    Replies:
    7
    Views:
    698
    Kanenas
    Feb 15, 2005
  3. Bram Stolk
    Replies:
    4
    Views:
    353
    Bram Stolk
    May 25, 2005
  4. Rene Pijlman
    Replies:
    6
    Views:
    701
    Fredrik Lundh
    May 29, 2006
  5. OtisUsenet
    Replies:
    1
    Views:
    658
    derek
    Sep 19, 2007
Loading...

Share This Page