“And then there’s that spec which fails only at the end of the month.. cause it asks the date picker to select the date ‘5 days from now’ :)”
Writing software that revolves around time can lead to hard to reproduce, sporadic test failures. Between varying timezones, politicians arbitrarily moving hours around, different numbered months, leap seconds/minutes, and a few other things that affect “time,” it really does seem like a very simple but difficult concept to work with.
I wish I could say this was an interesting post about programming “time,” but it’s not. All that fluff is to try justify some of my travel experiences from last week.
Last Tuesday, after a long day of work, I cleaned the apartment, packed my suitcase and headed to the airport for my red-eye flight. After having some initial troubles with the check-in kiosk I managed to get a hold one a customer suppport person to figure out why I couldn’t find my reservation.
She couldn’t find my reservation either! As soon as she finished her sentence I realized what had happened and immediately excused myself.
My flight was at 12:25 that morning. I interpreted “12:25 a.m. Nov 22” as “midnight after the 22nd.”
One of the problems with consistently staying awake until 1 or 2 a.m. means that I have a (bad) habit of lumping those hours in with the previous calendar day.
What’s more, this is actually the second time this happened this year. I made the exact same mistake with my return bus ticket from LA->SF last January.
After over 40 minutes on the phone with an airline representative who was not very good at hiding his indian accent, I had purchased a new ticket for the early next morning.
Having spent 5 hours overnight outside security at the airport, and instantly doubled the cost of my entire Thanksgiving trip, I’m hoping I’ve now learned from my mistake.