[#64210] Asking for clarification for exception handling usage — Rodrigo Rosenfeld Rosas <rr.rosas@...>
I've created a ticket for that but didn't get any feedback so I decided
[#64517] Fw: Re: Ruby and Rails to become Apache Incubator Project — Tetsuya Kitahata <[email protected]>
What do you think? >> Ruby developers
What benefits are there to this? I have a feeling that adding unnecessary
On Sat, 23 Aug 2014 22:43:46 -0700
Here I am a Japanese. Before moving anywhere else answer to our question first: what benefits?
tax issue with each other.
[#64614] cowspace (work-in-progress) — Eric Wong <normalperson@...>
Hi all, I started working on a cowspace branch. Based on the mspace API
[#64615] [ruby-trunk - Feature #10181] [Open] New method File.openat() — oss-ruby-lang@...
Issue #10181 has been reported by Technorama Ltd..
I like this feature.
On 08/28/2014 02:53 PM, Eric Wong wrote:
Joel VanderWerf <[email protected]> wrote:
On 08/29/2014 12:55 AM, Eric Wong wrote:
Joel VanderWerf <[email protected]> wrote:
[#64627] [ruby-trunk - Feature #10182] [PATCH] string.c: move frozen_strings table to rb_vm_t — ko1@...
Issue #10182 has been updated by Koichi Sasada.
[#64671] Fwd: [ruby-changes:35240] normal:r47322 (trunk): symbol.c (rb_sym2id): do not return garbage object — SASADA Koichi <ko1@...>
Why this fix solve your problem?
(2014/08/30 8:50), SASADA Koichi wrote:
SASADA Koichi <[email protected]> wrote:
Eric Wong <[email protected]> wrote:
(2014/08/31 0:18), Eric Wong wrote:
[ruby-core:64491] [ruby-trunk - Bug #10135] Time.at is inaccurate
Issue #10135 has been updated by David MacMahon.
John Smart wrote:
> I believe I have found an issue with Time.at. Many runtimes and DBs use milliseconds since epoch for recording time. Currently, the only way to generate a Time in ruby with milliseconds is:
>
> ~~~
> Time.at(milliseconds / 1000.0)
> ~~~
Another (better) way is:
~~~
Time.at(milliseconds.to_r / 1000)
~~~
That passes the non-integer seconds as a Rational rather than a Float so precision is maintained:
~~~
>> Time.at(1381089302195.to_r / 1000).strftime('%N')
=> "195000000"
# Modern Ruby (since 2.x?) can use 'r' suffix for literal Rationals
>> Time.at(1381089302195r / 1000).strftime('%N')
=> "195000000"
~~~
> It seems that somewhere in the MRI, someone is using floating-point math to represent a Time.
Actually, you were the one who started using floating point math to represent Time when you divided `milliseconds` by `1000.0`! :-)
----------------------------------------
Bug #10135: Time.at is inaccurate
https://bugs.ruby-lang.org/issues/10135#change-48438
* Author: John Smart
* Status: Open
* Priority: Low
* Assignee: Akira Tanaka
* Category:
* Target version: current: 2.2.0
* ruby -v: ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
I believe I have found an issue with Time.at. Many runtimes and DBs use milliseconds since epoch for recording time. Currently, the only way to generate a Time in ruby with milliseconds is:
~~~
Time.at(milliseconds / 1000.0)
~~~
However, this is inaccurate:
~~~
> Time.at(1381089302195 / 1000.0).to_f
=> 1381089302.1949997
> Time.at(1381089302195 / 1000.0).strftime('%3N')
=> "194"
~~~
This doesn't make much sense because you would expect:
~~~
> 1381089302195 / 1000.0
=> 1381089302.195
> (1381089302195 / 1000.0).to_f
=> 1381089302.195
~~~
It seems that somewhere in the MRI, someone is using floating-point math to represent a Time.
Is there any other way (workaround) to construct Time with millisecond accuracy?
--
https://bugs.ruby-lang.org/