Like you I think I've inadvertently become the "Dungeon Master". I don’t like maintaining a legacy app but if you’re going to replace this software the replacem

Like you I think I've inadvertently become the "Dungeon Master". I don’t like maintaining a legacy app but if you’re going to replace this software the replacement better be an improvement. > The dark secret of the Dungeon Master is that he knows every trap in the existing legacy software, because he was the one to leave the traps around. I take issue with this quote as well. In my experience, I know about the traps because I've seen what happens when they get triggered and had to recover from them - often at great time and expense. Put another way traps are edge cases and like any system it's easy to account for 90% of the complexity it's the remaining 10% of edge cases that cause the headaches. When I hear a young developer say something like "We’ll just use a const and assume each day is 24 hours long because it simplifies the code immensely". When I then point out they’ve stumbled into a trap because their program will now fail catastrophically twice a year (daylight savings, when you have a 23 and 25 hour day). I’m not doing it to be a curmudgeonly dungeon master trying to protect my turf. I’m pointing it out because I’ve dealt with that pain when I got bitten by DST in the app I maintain. I was young once too. It’s easy for some junior to say “This error will rarely occur it is not worth introducing complexity to handle it.” They aren't the ones who will get called out to fix it when the 'unlikely error' inevitably crops up. In the case of DST twice a year for the 15+ year life of the app adds up. Edit: I'm sure someone will mention UTC - I agree better to use this if underlying DB supports it.