RitzyMage

I have never worked on a system where simply storing everything as UTC isn't a perfect solution.

I know they exist, but I would say those are niche.

I firmly disagree with this, but I think that is because I think timestamps are very different than dates. Two examples my team runs into frequently that I think are very common:

1. Storing the time of an event at a physical location. These are not timestamps and I would never want to convert them to a different time zone. We had google calendar trying to be smart and convert it to user's local time because it was stored as a timestamp, but it is not a timestamp. I don't care where the user lives, they will need to show up Jan 2nd at 3pm. Period. I hate when tools try to auto-convert time zones 2. Storing "pure dates" (e.g. birthdays). The database we use does not allow this and we have to store birthdates in UTC. This is an abomination. I've seen so many bugs where our date libraries "helpfully" convert the time zone of bitthdays and put them a day before they actually are.

Storing UTC may solve almost all timestamp problems, but timestamp problems are a pretty narrow slice of date and time related bugs.

CS is definitely becoming a less profitable field, but I think blaming AI is naive and unfounded. A non-technical friend of mine tried coding with AI help for a week his opinion is that "AI is not nearly as useful as people are making it out to be". I agree. I use AI for certain small tasks, but it is WORLDS away from being able to write a full app, much less a complete architecture. It is completely incompetent in the truly difficult parts of computer science.

Deploying next is difficult, but IMO that's because deploying anything substantial is difficult. I've had my share of nasty deployment debugging that took days and none of it was due to next. (the biggest offenders I've seen are (1) random open source software no one on my team is an expert on, (2) docker / kubernetes, (3) databases, and (4) integration hell)