time:schedule-event should handle times less than one millisecond in the future

[SFRailsback]

time:schedule-event takes an argument that is the future time at which the event is to be scheduled. When ticks are associated with logotimes (via time:anchor-schedule), then this argument can be a logotime.

When that logotime is less than one millisecond past the current time, schedule-event raises an error, saying that you tried to schedule an event in the past. We ought to be able to catch and prevent this error, and instead put the event at the top of the event queue so it is next for execution.

This problem is important because it is standard in discrete event simulation to use random-exponential to determine the time between events, and random-exponential often produces very small values.

The Library model Distribution Center Discrete Event Simulator provides an example, at lines 166-170. The commented-out statement
time:schedule-event "observer" [ -> receive-an-order ] time:plus sim-time time-to-next-order "minutes"
would always work if this problem was fixed, but it currently raises an error occasionally.

[TheBizzle]

I agree that you should be able to do this somehow. Where I'm less certain is what the best solution to the problem would look like, in the language.

Am I wrong in thinking that, sometimes, an event really is being scheduled for a time that's past, and should be ignored? It feels to me like that shouldn't generate an error. My intuition is that there should maybe be a time:queue-event that serves as a counterpart to schedule-event, where schedule-event ignores things scheduled for the past, whereas queue-event runs them immediately. Alternatively, this could be expressed with an optional boolean argument to the schedule-event primitive.

Either way, it sounds to me like scheduling an event for the current time is generating an error, which also sounds wrong to me. The current time is not even in the past! And the docs say:

If tick-or-time is in the past (less than the current tick/time), a run-time error is raised.

With no mention of if the argument is the current tick/time.

[SFRailsback]

Hi Jason, thanks for looking at this. I think the right solution is just fixing the code so that if the scheduled time is between zero (to the precision of the computer) and 1 millisecond from the current time, then schedule the event at the current time. (Whereas now, apparently, such an event raises an error.) Steve

…

On 2/21/2026 8:14 PM, Jason Bertsche wrote: *TheBizzle* left a comment (NetLogo/Time-Extension#53) <https:// github.com/NetLogo/Time-Extension/issues/53#issuecomment-3939836446> I agree that you should be able to do this somehow. Where I'm less certain is what the best solution to the problem would look like, in the language. Am I wrong in thinking that, sometimes, an event really /is/ being scheduled for a time that's past, and should be ignored? It feels to me like that shouldn't generate an error. My intuition is that there should maybe be a |time:queue-event| that serves as a counterpart to |schedule- event|, where |schedule-event| ignores things scheduled for the past, whereas |queue-event| runs them immediately. Alternatively, this could be expressed with an optional boolean argument to the |schedule-event| primitive. Either way, it sounds to me like scheduling an event for the /current/ time is generating an error, which also sounds wrong to me. The current time is not even in the past! And the docs say: If |tick-or-time| is in the past (less than the current tick/time), a run-time error is raised.

-- Steve Railsback Lang Railsback & Associates Arcata, California

[TheBizzle]

The issue runs deeper than that, and has a basis in IEEE floating point arithmetic standard. This standard is why, when you run 0.1 + 0.2 in NetLogo (or any other language that I know of), the result is not the expected 0.3 but 0.30000000000000004. By performing arithmetic on floating point numbers, the numbers can be nudged into slightly different values than conventional math would tell us they should result in.

Something similar is happening when times are being converted to and from tick values and LogoTimes, in this extension. For some particular tick values, they can be converted to a LogoTime and then back to a tick value, and (in so doing) produce a number that is actually slightly smaller than the tick value that was started with, due to floating point math discrepancies.

Since this extension aims to be compatible with both of these representations of time, and the representations do not map cleanly onto one another, the result is that some argument values will get scheduled for times that are very slightly in the past (as far as the math is concerned).

As a result, if we want to fix this, then I think the API needs to change to allow the NetLogo programmer to be able to specify their desired behavior for running events that were scheduled in the past, or we need to explore options that are a bit more magical, with the risk that they could possibly lead to other unexpected behavior. I think the best idea that @ERSUCC and I had for how this could be improved is to immediately run events that were scheduled less than 1 tick in the past, and to error otherwise.

[SFRailsback]

On 2/23/2026 4:06 PM, Jason Bertsche wrote: I think the best idea that @ERSUCC <https://github.com/ERSUCC> and I had for how this could be improved is to immediately run events that were scheduled less than 1 tick in the past, and to error otherwise.

I agree that a simple rule like this is the best way to handle the error. But it would be safer (catch more errors) and more in line with the extension's stated resolution of 1 millisecond to make the rule: run events that were scheduled less than 1 millisecond in the past, and error otherwise. Would it work to do this for time:schedule-event agent anonymous-command tick-or-time and time:schedule-event-shuffled - If tick-or-time is a tick (not a logotime) then raise an error if it is negative by at least one tick. (I have never had a problem when using ticks). - If tick-or-time is a logotime, then raise an error if it is negative by 1 millisecond or more. Thank you! Steve -- Steve Railsback Lang Railsback & Associates Arcata, California

[ERSUCC]

I don't see any reason to change the behavior of tick inputs, because the issue only occurs with logotimes. But for logotime inputs, 1 millisecond of wiggle room sounds good to me.

EDIT: On second thought, maybe this is not a good idea. If the user specifies that 1 tick equals 1 year, for example, 1 millisecond probably won't be enough time to account for this error. However, scheduling something 6 months in the past would almost certainly be user error in that case, so we would want to catch that. Not sure what the best path forward is, unless we can determine that 1 millisecond is enough for longer tick lengths.