When midnight isn’t midnight

Michael Lambert
Tapendium Engineering
2 min readNov 5, 2021

--

Digital clock font with time 24:00:00

The Tapendium Engineering Team recently encountered a bug when submitting a request to a third-party API. The timestamp submitted with a request used “24” instead of “00” for the hour beginning at midnight. This is a summary of what was found.

The problem was first noticed when a failed order notification was received through one of our monitoring systems. Replication of the fault was attempted, but of course everything worked during business hours. Without the ability to replicate the issue the team was unable to determine a fix. Further investigation of the logs was undertaken and it was noticed that times between midnight and one am were sent with a time of “24” instead of “00”.

At this point I’ll digress a little from the issue at hand and provide some details about our tech stack. The service in question is running in AWS Lambda, using NodeJS as the runtime. We use Luxon for date/time handling in this service.

Now the problem and replication steps were defined a hotfix was created and deployed. The hotfix was simple, replace T24: with T00: in the API call. It isn’t pretty, but it works and enabled the team to undertake a proper fault-finding mission.

The next morning, in the daily tech huddle, time was devoted to exploring the issue, with the entire team coming along on the journey.

It was discovered that the issue had been logged with Luxon in March 2020 with the subject Unexpected 24-hour time format in en-AU. It turns out Luxon relies on the Intl API, and the bug is outside of Luxon’s scope.

It was also discovered that the bug appears in NodeJS and Chrome, but doesn’t occur in FireFox.

A similar bug report to the Luxon one was discovered in the Google Chrome Help community with the Chrome 80 shows timestamp “24:00” instead of “00:00”. Unfortunately the thread only had two replies confirming the issue and had been locked.

The team began thinking about the similarities between Chrome and NodeJS that weren’t shared with FireFox. The only item we could think of was the V8 Javascript Engine. This seems like a logical place for the error to be occurring, but without enough knowledge of V8 we aren’t really sure how we can get a fix done.

The team ended up tweeting to see if we could get any help with this issue.

As an interesting aside, when looking at the V8 source code, it appears that V8 will use 24:00:00.000 as a valid time, but 00:00:00.001 beyond that. My understanding of times makes me think this is correct, but I don’t think many systems not based on V8js would support it.

--

--

Michael Lambert
Tapendium Engineering

Human-centric SaaS Professional | People Leadership & Mentoring | Technical, Product & Delivery Management