Closed ilyakuzmin closed 3 months ago
Seems like you have a good handle on this. Can you create a PR?
Was thinking about this and wanted to see more test cases. Seems like the correct behavior is to keep the Date part and only change the time
3.0.1 :002 > Time.now
=> 2023-11-02 07:30:29.518102 -0700
3.0.1 :003 > DateTime.parse('06:00:00')
=> Thu, 02 Nov 2023 06:00:00 +0000
3.0.1 :004 > DateTime.parse('01:00:00')
=> Thu, 02 Nov 2023 01:00:00 +0000
3.0.1 :005 > DateTime.parse('15:00:00')
=> Thu, 02 Nov 2023 15:00:00 +0000
It depends on frozen time you use. Not sure what we can do with all this case
in parse_with_mock_date
, too much variations
case 1 correct
> Time.now
2022-08-02 09:50:00 +0300
> DateTime.parse("15:00:00")
Tue, 02 Aug 2022 15:00:00 +0000
> Timecop.top_stack_item
#<Timecop::TimeStackItem:... @travel_offset=-39521870.819318704
> 39521870.0 / 60 / 60 / 24
457.429050925926
> Timecop.top_stack_item.travel_offset_days
-457
case 2 incorrect
> Time.now
2022-08-02 05:50:00 +0300
> DateTime.parse("15:00:00")
Mon, 01 Aug 2022 15:00:00 +0000
> Timecop.top_stack_item
#<Timecop::TimeStackItem:... @travel_offset=-39536896.712171
> 39536896.0 / 60 / 60 / 24
457.602962962963
> Timecop.top_stack_item.travel_offset_days
-458
@ilyakuzmin does this fix it?
I am going to merge that fix. Please reopen @ilyakuzmin if this issue is not fixed on main
I assume it's about
round
forTimeStackItem#travel_offset_days
Or need one more case for
parse_with_mock_date