Turned out our backend team just had a graphql type def that was wrong. That resulted in a nullified value, and the server logic following that treats a null value for the timestamp to mean the task should be completed now. None of this was reflected in the UI however.
So all in all, my bug wasn't that exciting, but if you think about the early chaotic days of a startup, there are often nuances in dealing with date and time that don't get thought through, particularly with newer developers being pushed or pushing themselves to get things launched. For example, if you are doing all of your testing locally, you might not find out until you get a user or customer in another time zone that, hey, we should have thought about that.
Bottom line is, and I think this is really what I was thinking this morning -- I would never sink so much time into drawing conclusions with the early data of a startup like this. Life is too short. If I am going to spend that much time on something it's going to need to be a less risky investment.
Not OP, but I work on an app that collects network data from various customer systems, and have run into lots of 'fun' time-related bugs. An instance of the app runs on a machine on the customer network (that we don't control), and this is very often "the one server" that particular customer has.
One thing I've been shocked by is how wrong the clocks often are -- to the point that our software tracks the offset from real time (our server) and adjusts all collected timestamps. It's often a minute or two off (which means the customer is not using NTP sync), but many times it's been several days or even years off. One of the things that led us to adding the time adjustment was a bug report that was initially something like "The UI says 'Data last updated in 5 years' but it was really a few minutes ago" -- that was a result of accepting data as-is from a server with a clock set 5 years in the future.
Another fun bug that sticks out in my head was caused by a system that was sending time strings using custom formatting, where the original developer either accidentally specified hours as 12-hour (instead of 24-hour) format or forgot the "AM/PM" (I am not sure which). On the receiving end, a fairly forgiving parsing method was being used and because there was no "AM/PM" it was being read as if it was 24-hour format, so what was really "7PM" was being parsed as "7AM". Worse, this wasn't even that obvious as a problem, because data naturally followed business hours (eg, <12 hours window of active time per day, usually without overlapping) and was being collected from many time zones. It was only visible if you really dug into the data, knew what was expected from the source data, and checked using data in collected in the afternoon of the client timezone.
So all in all, my bug wasn't that exciting, but if you think about the early chaotic days of a startup, there are often nuances in dealing with date and time that don't get thought through, particularly with newer developers being pushed or pushing themselves to get things launched. For example, if you are doing all of your testing locally, you might not find out until you get a user or customer in another time zone that, hey, we should have thought about that.
Bottom line is, and I think this is really what I was thinking this morning -- I would never sink so much time into drawing conclusions with the early data of a startup like this. Life is too short. If I am going to spend that much time on something it's going to need to be a less risky investment.