In a previous life, the speaker was your run of the mill software consultant, who had the privilege of working in a lot of different industries.
Nowadays he spends his time as a mere forensic software engineer, learning to use and appreciate software engineering from a different perspective.
In his free time, he likes to tinker around with games, emulators, compilers and of course digital forensics.
When asking GPT4 if it is difficult to parse dates in Java, it replied:
Ah, parsing dates in Java. It's the kind of task that sounds so simple, you might think it's a first-week-of-coding-bootcamp kind of problem. But oh, how wrong you would be! It's more like a "I've been coding for ten years and I still get nightmares about this" kind of problem.
Which is a fair answer. If you've never experienced the anguish of time-travel when you're parsing a date, then you haven't tried hard enough.
This is partly caused by API design choices (looking at you `new Date(0) != new Date()`), but generally speaking stems from the fact that dates, calendars, locales, leap seconds, leap years, time-zones...etc, are just very complicated.
But parsing data always serves a purpose, and we frequently attempt to tailor the data to fit our needs, although it's usually the opposite that's true. The main goal is parsing the data itself. When you're faced with the challenge of consuming an API from Evil Corp, which had the audacity to create a proprietary date format, your managers likely won't care (or understand) why none of your sophisticated libraries can handle it.
This talkwill navigate the treacherous terrain of our beloved APIs, while also highlighting the traps in our thought processes. So buckle up for a conclusion that promises solutions wrapped in humorous anecdotes (with a pinch of date forensics).
Searching for speaker images...