Python and time: five functions so your code stops breaking on Mondays

If you've ever tried to feed neural networks data collected from different sources, you know: time is the most insidious data type. Everything seems simple enough, but the moment one system outputs a date in American format and another in ISO, your perfectly tuned pipeline turns into a pumpkin. Python in this regard is an old faithful friend who sometimes acts strange. Its standard datetime library is powerful, but it requires the kind of discipline that raw internet data simply doesn't have. We constantly encounter data arriving as strings like "2 hours ago" or "March 15th," and forcing an LLM to parse this in real time is an expensive proposition.

The first problem that proper parsing functions solve is relative dates. Imagine you're collecting news to train a model. The text "yesterday" or "three days ago" is absolutely useless unless you tie it to a specific point on the timeline. Writing a function that converts such expressions into absolute values isn't just a convenience—it's a necessity for maintaining chronological accuracy in your dataset. Without this, your model risks confusing cause and effect simply because the data in its "memory" got scrambled.

The second headache is the format wars between the US and the rest of the world. January 12th or December 1st? If your code lacks clear logic for handling DD/MM and MM/DD with source context in mind, you'll eventually run into errors that are extremely difficult to catch on large data volumes. Creating a wrapper function that validates dates and attempts to guess the format based on frequency or source metadata saves hours of manual database cleaning. This is the case where a small dose of input automation prevents disaster at the output.

And let's not forget about time zones, that "final boss" of programming. Many developers make the mistake of ignoring UTC offsets until the project starts scaling. When your users or data sources are scattered across the globe, storing time in "naive" form—without any timezone binding—is a recipe for a bug that will surface at the most inconvenient moment. A custom function that forcibly converts any incoming data stream to UTC and adds a timezone label should be in the arsenal of anyone working with analytics or AI.

Why is this critical right now? In the era of RAG systems (Retrieval-Augmented Generation), the accuracy of information retrieval depends on how well your data is structured. If your search index returns a document from 2022 instead of 2024 due to a date parsing error, the neural network will confidently hallucinate. Clean data at the input is the only way to get an adequate result at the output. Using lightweight DIY functions instead of heavy dependencies like Pandas where unnecessary also speeds up your scripts, which is critical for high-load systems.

Ultimately, working with dates is a matter of code hygiene. You can use the most advanced models like o1 or Claude 3.5, but if you feed them garbage, you'll get garbage out. Five simple functions for normalizing dates, handling relative time, and unifying time zones—that's the foundation on which reliable data handling is built. This isn't innovation, it's common sense dressed up in a few lines of Python.

The key point: don't rely on data always arriving in the correct format. Write your own cleaning tools once, and you'll forget about datetime problems forever.