| I work with a proprietary programming language that internally models a date_time as a UNIX epoch offset. The to_string method of a date_time results in a nice human readable string in the local timezone, but crucially not including the TZ itself. There were also accessors for the HH:MM:SS parts of the date_time. At some point, the problem must've come up "if it's 5pm here in SFO, what time is it in MIA?", or some variation on that theme. Someone decided that the best way to answer this was to write a function that took a date_time, then altered it to apply an offset between timezones. e.g. time_local_to_tz. So you can could take a date_time in SFO, do time_local_to_tz (supplying Miami's TZ) and get back a date_time value that would to_string in SFO to show "the time in MIA". These functions made their way into a standard library and then to a lot of code. The only problem is that the assumptions are literally all wrong. Adding the offset changes the actual point in time being addressed, which can change the timezone in effect in the current location, which results in the result skewing. This was compounded by some developers assuming that maybe they should convert their times to UTC before persisting them. Of course, the usage of these functions is now embedded in a bunch of code no-one dares to touch, because it is full of hacks to "make it work" and quite possibly there is other code somewhere else (separated by a network connection, or a file, or persistence into a database) that is predicated on undoing those same set of hacks. |
The app was for displaying time-series data. The data displayed was only generated during business hours. We usually wanted to view a span of a couple of weeks. Displaying it naively, with real time along the x-axis would mean that three-quarters of the display was blank, with only 40 of a week's 168 hours in use.
The obvious thing to do is to elide the blank bits, and just show the spans of time with data (with a little gap in between). But the charting library i was using didn't have the concept of a discontinuous or nonlinear x-axis.
So i wrote a class called TimeCompressor that would collect a set of time-series data, indexed by epoch timestamp, and rewrite the timestamps so that empty spans of time would be compressed. The earliest timestamp in the dataset stays the same, but later ones may be slid earlier in time to compress empty spans. The resulting indices are numbers which look mostly like epoch timestamps, and in some cases actually are epoch timestamps, but really aren't epoch timestamps.
This was all done in JavaScript, so there wasn't a convenient way to wrap the not-really-timestamp indices in a type to mark them as such. So, in this application, when there's a field called somethingTimestamp and it has a large integer that looks like a timestamp in it, sometimes it's a timestamp, and sometimes it isn't!
I am hoping this application will be retired before i ever need to work on it again.