Community
Chat Logs
Friday, October 16, 2026 (America/New_York)
- dreamrealhttps://bytecode.news/posts/2026/10/emergent-design-outside-the-codebase
- dreamrealIf anyone has a hacker news or lobste.rs account, AND if you think it's worthwhile, would appreciate a posting about it
- dreamrealif *I* post it it's self-promotion
- dreamrealhttps://bytecode.news/posts/2026/10/the-geometric-model-of-maintenance was posted today as well
- Chronosdreamreal: Two thumbs up for the emergent design article
- dreamrealgrazi
- cheeservictor?
- dreamrealpfft
- mrfbAnyone know where I can find details on how Java gets system time on Windows, specifically for OffsetDateTime.now(), besides reading the JDK source? I'm investigating a clock resolution issue and wondering how much depends on the JDK vs Windows itself
- julemand101mrfb: So your issue are no longer that you could not see nanoseconds added to the OffsetDateTime object?
- mrfbjulemand101: Right, the nanoseconds are added correctly, and increasing the increment to 1 ms addressed the initial failures. But you were right in your review comment about EventAggregator using its own clock. That issue doesn't reproduce on my Windows VM, only in CI. I managed to reproduce the exact failure locally on Linux by truncating OffsetDateTime.now() to seconds. Now I'm trying to understand
- mrfbhow Java gets the system time on Windows. I suspect there might be some Windows API weirdness involved, especially since I can't reproduce it on my VM but it fails intermittently in CI.
- mrfbjulemand101++
- nevetjulemand101 now has karma of 3.
- julemand101mrfb: Could be your CI are running on a platform that does not allow nano-second precesion?
- mrfbthats an interesting question worth investigating
- julemand101mrfb: But to answer your question, it is done by the following on Windows in Java 21: https://github.com/openjdk/jdk21/blob/master/src/hotspot/os/windows/os_windows.cpp#1079-1086
- mrfbYeah, I went the rabbit hole and was looking into it, following VM.getNanoTimeAdjustment()
- ernimrilmrfb, I remember seeing java on windows having bad time resolution (a few hundred millis) on some virtual machines, but that was several years ago, I have not checked if that is still the case (I typically do not run windows)
- ernimrilso the timing was better than seconds, but not by much
- mrfbMe neither, I only use windows when I need to run tests or similar cases. Makes sense and seems things didnt improve much
- mrfbThe OpenJDK implementation looks reasonable: it reads the Windows system time and converts the FILETIME value into seconds and nanoseconds, But the conversion doesn't guarantee the underlying clock provides that resolution. so the JVM maybe represents the timestamps with nanoseconds while the windows API return the same value across several consecutive calls
- ernimrilthat is what we did see, asking for time in a loop and it jumped like every few hundred millis, showing no difference in between
- ernimrilso we got time like: x, x, x, x, y (= x + 200), y, y, y, y, z (= y + 300) ....
- mrfbThat's exactly the behaviour I suspect we're seeing in CI. I've traced OpenJDK down to GetSystemTimeAsFileTime(), so the clock resolution on those Windows VMs might explain it.
- mrfbGood news, I think I can rule out Java as the culprit and focus on Windows clock resolution instead.
- ernimrilmight be a good time to ask your infrastructure guy if they can improve the vm time resolution
- mrfbwhile not wrong, I think the test should not depend on clock resolution
- mrfbJust a curious observation, the go client pass a clock that advances time deterministically, the Java implementation while is almost on par, uses the OffsetDateTime.now() mention before. The test follow also the go implementation assuming both timestamps wont be similar but thats not true thanks to windows clock resolution
- mrfband by the way, thanks for the pointers again
- NeXeNi didn't notice if you thought to try but maybe use a mock clock?
- NeXeNi mean if you're not testing for the precision of the os or something obviously, but you could just mock it so that you'll reliably test the conditions you want to know are supposed to be happening
- NeXeNone thing about a mock clock you gotta be careful of tho, is that you're only testing what "should" happen in a perfect environment. you still have the underlying imprecision and timing issues
- NeXeNi always bypass precision issues with iterated increments, so that you can always add a distinguishing mark to the timestamp so no two can be the same
- NeXeNbut if you're getting a stream from a device that has a really accurate clock (i've encountered this with a dsp plugin) and you have something with less than stellar, then you have to find how to mash it. if the monotonic won't work for your app, wall clock is never going to be any better period
- NeXeNi mean you can do vector clocks and idempotency keys, but i prefer sequences
- NeXeNmostly because it's simple
- NeXeNntp will be easy, but ptp is i think time right at your nic
- NeXeNe.g. without the stack latency
- NeXeNhttps://techdocs.broadcom.com/us/en/storage-and-ethernet-connectivity/ethernet-nic-controllers/bcm957xxx/adapters/Configuration-adapter/precision-time-protocol/ptp-specification.html and https://docs.kernel.org/networking/timestamping.html look good but i'm going to be honest. i am running on caffiene fumes
- nevethttps://techdocs.broadcom.com/us/en/storage-and-ethernet-connectivity/ethernet-nic-controllers/bcm957xxx/adapters/Configuration-adapter/precision-time-protocol/ptp-specification.html "PTP Specification" || https://docs.kernel.org/networking/timestamping.html "Timestamping — The Linux Kernel documentation"
- NeXeNSO_TIMESTAMP Generates a timestamp for each incoming packet in (not necessarily monotonic) system time. Reports the timestamp via recvmsg() in a control message in usec resolution. <--- yeah in the kernel docs it says you can get it for the incoming packet
- NeXeNEvent messages: Time-critical messages with an accurate timestamp that is generated at both the transmit time and receive time. <----from the spec
- NeXeNlike was said earlier, speak to sysadmin :P
- NeXeNoh i see what you said about the go client. yeah if you inject a clock that's a winner