Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Time#strftime incorrectly formats sub-second values #5139

Closed
rdubya opened this issue Apr 12, 2018 · 2 comments
Closed

Time#strftime incorrectly formats sub-second values #5139

rdubya opened this issue Apr 12, 2018 · 2 comments
Milestone
Invalid or Duplicate

Comments

@rdubya
Copy link

rdubya commented Apr 12, 2018

Environment

jruby 9.1.16.0 (2.3.3) 2018-02-21 8f3f95a Java HotSpot(TM) 64-Bit Server VM 25.77-b03 on 1.8.0_77-b03 +jit [darwin-x86_64]

java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Expected Behavior

When building RubyTime objects with a DateTime object, it should correctly handle string formatting sub-second values.

jruby-9.1.16.0 :001 > now = Time.now
 => 2018-04-12 16:35:21 -0400
jruby-9.1.16.0 :002 > now.usec
 => 952129
jruby-9.1.16.0 :003 > now.strftime('%6N')
 => "952129"
jruby-9.1.16.0 :004 > now.nsec
 => 952129000
jruby-9.1.16.0 :005 > now.strftime('%9N')
 => "952129000"

Actual Behavior

It shifts the values to the right 3 decimal places:

jruby-9.1.16.0 :001 > zone = org.joda.time.DateTimeZone.forOffsetMillis(0)
 => #<Java::OrgJodaTime::UTCDateTimeZone:0x778d1062>
jruby-9.1.16.0 :002 > dateTime = org.joda.time.DateTime.new(2018, 4, 12, 20, 22, 10, 0, zone)
 => #<Java::OrgJodaTime::DateTime:0x4386f16>
jruby-9.1.16.0 :003 > time = org.jruby.RubyTime.newTime(JRuby.runtime, dateTime, 20948000)
 => 2018-04-12 20:22:10 UTC
jruby-9.1.16.0 :004 > time.usec
 => 20948
jruby-9.1.16.0 :005 > time.strftime('%6N')
 => "000209"
jruby-9.1.16.0 :006 > time.nsec
 => 20948000
jruby-9.1.16.0 :007 > time.strftime('%9N')
 => "000209480"
@enebo
Copy link
Member

enebo commented Apr 12, 2018

Extra note: The actual behavior part of this is what we are doing in AR-JDBC. We are unsure if we are constructing this Time instance improperly or our strftime is broken in some way that this code path exposes.

@enebo enebo added this to the Invalid or Duplicate milestone Apr 12, 2018
@enebo
Copy link
Member

enebo commented Apr 12, 2018

Ok I think this is won't fix. The formatter relies on dt.getMillisOfSecond() to return millis and we set it to 0 from the parsing code above (which sets either nanos or millis but not both). So we need both values for our fstrtime method to work. This is an error in ARJDBC.

@enebo enebo closed this as completed Apr 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Invalid or Duplicate
Development

No branches or pull requests
2 participants
@enebo @rdubya