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.

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

Inaccurate timing with a very fast clock #66

Open
knbx opened this issue Aug 21, 2023 · 1 comment
Open

Inaccurate timing with a very fast clock #66

knbx opened this issue Aug 21, 2023 · 1 comment

Comments

@knbx
Copy link

knbx commented Aug 21, 2023

Hi there

I really like this library, so I thought I'd mention some weird behaviour I encountered while unit testing.

I set my clock rate at x100 to speed everything up during tests, but noticed some inaccuracies while doing this. Maybe this is just an example of #42 ?

	var cancels: [AnyCancellable] = []
	let fixedStart = Clocks.system.nextHour().firstInstant
	let fastClock = Clocks.custom(startingFrom: fixedStart, rate: 100)

	fastClock
		.chime(at: fastClock.thisSecond() + .seconds(10))
		.sink { _ in
			print("chimed at \(fastClock.now().date)")
		}
		.store(in: &cancels)

	fastClock
		.chime(at: fastClock.thisSecond() + .seconds(17))
		.sink { _ in
			print("chimed at \(fastClock.now().date)")
		}
		.store(in: &cancels)

	//        chimed at 2023-08-21 12:00:10 +0000
	//        chimed at 2023-08-21 12:00:47 +0000

The first chime works as expected, but for any value above 17 'seconds' the timing is off.

@Mordil
Copy link
Contributor

Mordil commented Apr 11, 2024

If this was implemented, would it solve your use case potentially? #83

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants