Who would be a programmer? Always under pressure to make features ‘just a little bit better’, all the while watching over our shoulders as ChatGPT and AI show why it is likely to replace us all over the next few years!! And then you get hassle because you can’t make a straightforward date field work - I mean, why are we getting paid at all!!!
In all fairness, life in a development team is not all bad, but it is surprising just how much trouble dates and times give developers, although perhaps it shouldn’t be when you look at one really simple problem: US-format vs UK-format. Here in Blighty (I can’t bring myself to call it Great Britain right now), we like to put the day number first, then the month and then the year, whereas our erstwhile friends across the Atlantic prefer to put the month before the day.
Does that really matter? Well, to a programmer this is a disaster, not least because for the first twelve days of every month there is absolutely no certain way to know what the date actually is - whether 5/4/2023 means 5th April or 4th May only a Jedi Master could tell you (too oblique?).
At nettTracker, this ambiguity is compounded because about half of our Company connections come from regions that use US date formats while our servers operate in European time zones. The way we deal with this is to inspect the region properties of the Company when it is first being connected to nettTracker and assign a date format accordingly. Our user interface (UI) then adjusts its date formatting according to the company and it all works very nicely. But with data input, things can get tricker.
Most UI systems utilise something called UTC or coordinated universal time, to encode a date and time value when sending it over the wire. This effectively resolves the problem of understanding whether a date is US, UK or any other format. UTC also includes a timezone component to assist the consumer know how the value compares to their current location, -8 indicating PST for example, showing it is 8 behind GMT. However, if the developer doesn’t pay really close attention, they may not realise that their code has translated the date and time value into their own timezone.
Why is this a problem?
When our servers receive a UTC date, it gets automatically shifted into GMT or BST. This means that any user in LA working after 4pm local time, will effectively be in the following day relative to the server. If a user was to submit a request that included a date, it is entirely possible that the servers would silently change this date to the next day and no one would notice.
Naturally, we have strategies to deal with these eventualities, but every now and then something slips through the net as we found last week. A new tool for changing the year-end date was not being correctly parsed and this resulted in a financial year with 13 months by mistake! A simple fix and a slapped wrist later, all is happy again, but it just goes to show how easy it is for something so simple to become such a problem.
Things like this are a great reminder why programmers are probably not going to be replaced by AI just yet…although, maybe they would not have missed the problem in the first place!!!