Summary

Follow-up to #7118. That PR fixed nxf_date for uutils coreutils, but in doing so it replaced the single date +%s%3N invocation with two separate calls:

s=$(date +%s)
n=$(date +%N)

This reintroduces a subtle timing bug. The two date processes are sampled at slightly different instants, so a second boundary can fall between them: %s is read in second K, then %N is read just after the tick into second K+1, when the nanosecond fraction has reset to near zero. The result is a timestamp that is up to ~1000 ms behind the true time.

nxf_date is used to record task start/complete times for trace metrics. Because the skew only ever under-estimates (seconds are read first and can only lag), a delta = end - start where the end call straddles a boundary can come out smaller than the real duration — and for very short tasks, even slightly negative. The original single-call implementation sampled both fields atomically and never had this problem.

Change

Read both fields from a single date invocation so they cannot straddle a second boundary:

read s n < <(date '+%s %N')

All the platform-handling logic introduced in #7118 is preserved unchanged:

• GNU coreutils — 9-digit %N, used directly.
• uutils coreutils (Ubuntu 26.04+) — leading zeros stripped from %N; re-padded to 9 digits via printf '%09d' so the millisecond extraction stays correct.
• BSD/macOS — %N yields a non-numeric literal (N); the regex check falls back to second precision.

date '+%s %N' is a single strftime/fork, supported identically wherever the per-field calls were, so there is no new portability cost — only the loss of the inter-call gap.

Test plan

• :nextflow:test --tests BashWrapperBuilderTest passes after updating both wrapper fixtures (test-bash-wrapper.txt, test-bash-wrapper-with-trace.txt)
• CI runs full test suite

🤖 Generated with Claude Code