Time generator with microseconds

[razorcd]

No description provided.

[b264]

The entropy leak in the determinism test failure is because Time.now will not return the same result on successive runs with the same seed. If Time.now is used, the user should pass it as an argument. This way, the gem always returns the same value on the same input with the same seed.

[razorcd]

to avoid using FactoryHelper::Config.random.rand here is a not so nice alternative:

      def randomize value
        result = value+1
        while result >= value   # needed because if value = 12_555_555, the block randomizes up to 12_999_999
          thousands = value.to_s.length/3
          remain = value / 1000**thousands
          result_arr = [(0..remain).to_a.sample(:random => FactoryHelper::Config.random) * (1000**thousands)]
          thousands.times do |index|
            result_arr << (0..1000).to_a.sample(:random => FactoryHelper::Config.random) * (1000**(thousands-index-1))
          end
          result = result_arr.inject(&:+)
        end
        result
      end

[NikitaAvvakumov]

Why avoid the existing randomizer?

[NikitaAvvakumov]

"Expected < #{a_minute_later},..."

[NikitaAvvakumov]

Looks good, @razorcd!

[NikitaAvvakumov]

Why not

def random_time_simple(from, to)
  time_diff = to - from
  rand_time = FactoryHelper::Config.random.rand(time_diff - 1) + 1
  from + rand_time
end

5.times do
  puts random_time_simple(Time.now - 1, Time.now + 1).iso8601(7)
end

# => 2015-11-22T00:42:24.0341640+02:00
# => 2015-11-22T00:42:23.7815417+02:00
# => 2015-11-22T00:42:23.9767937+02:00
# => 2015-11-22T00:42:24.1995736+02:00
# => 2015-11-22T00:42:24.2099311+02:00

This seems to address the original problem of Time.between returning whole-second timestamps.

Also, the exclusion of the two boundaries (from & to) via the -1 and +1 in the random_time method appears to be inconsistent with other gem methods that return a random value from a range. e.g. FH::Time & FH::Date do not do this.

[razorcd]

the problem here is that - 1 will subtract 1 second and not 1 nanosecond.

But I think this will work:
time_diff = (to - from).round(9) #=> returns seconds with 9 digits
Needs rounding because (to - from = 0.0000000019999999...) because of limited nr of bits in a float.
and
FactoryHelper::Config.random.rand(time_diff - 0.000000001) + 0.000000001

But even so, .rand will generate more digits than we need. (If we add .floor, it will not work with digits and if we add .random(9), it might round to next nanosecond).
It looks simpler but might complicate the logic.

This - 1) + 1 is there just to exclude the defined from and to times at the nanosecond level.
Between means all dates between the from and to and not between and included. So I considered just avoiding from and to from the end result (at nanosecond level only!).

E.g.

from = ::Time.local(2012, 05, 05,  05,  05,  30, 222_222.222)
to = ::Time.local(2012, 05, 05,  05,  05,  30, 222_222.224)
FactoryHelper::Timestamps.between(from, to) #=> always returns 2012-05-05 05:05:30 +0300
FactoryHelper::Timestamps.between(from, to).nsec #=> always returns 222222223
#as expected
# maybe we should add these to the tests too :)

[razorcd]

I am still not sure which default value to use fot to =
Because ruby will accept anything, even Time.local(999999999999999, 12, 31, 23, 23, 59, 999_999.999).

[b264]

If we have to pick a time, which is unfortunate but due to not being able to overflow Ruby, I would pick the Unix time at 0b01111111_11111111_11111111_11111111_11111111_11111111_11111111_11111111 aka the max signed 64-bit integer

[razorcd]

yes but:

Time.at(0b01111111_11111111_11111111_11111111_11111111_11111111_11111111_11111111) #=> 292277026596-12-04 17:30:07 +0200

it's a good idea but it is not very practical

[b264]

Perhaps 0b01111111_11111111_11111111_11111111 is the Unix Millennium Bug then.

[razorcd]

NOTICE I also responded at your comment. GitHub closes it because it's on outdated code.
Find it here:
#63 (diff)

[razorcd]

strftime_nsec will show a more readable error:

Expected > "2015-12-03 17:30:02 8936975250nsec +0200", but got 2015-12-03 17:29:58 6061458480nsec +0200.

[razorcd]

should we add this as a Reminder/Notice in the docs?

Any operation with a Time instance at a level smaller than 1 second should be followed by
a rounding because floating point operations are inaccurate.
e.g. (Time.now + 0.000_000_001).round(9)

[b264]

👍