Tomorrow is Mañana!

Dates and times are horrifyingly easy to screw up. For most projects, you don't run into real date/time issues for a while.  In some projects, you may not run into them at all.  When you do run into them - watch out!  All of a sudden Rod Serling steps out and says, "you are about to enter a new dimension..." Why is this?  OK, I can get a little abstract...  philosophical... and  say that since we have no control of time as a dimension, we tend to treat it like a nice, even progression.  Hey, SYSDATE here, getCurrentTimeMillis() there, '%y-%m-%d %H:%M:%S' another place.  It is all so straightforward. So when does this fail?  Typically, converting between binary and character representation is a typical culprit.  Don't do it!  Except... what happens when you need to reason about 'end of day' or 'close of business'?  So - you have to do it.  Then comes daylight savings time to screw things up - spring forward, fall back, keel over.  Didn't know that Florida has two time zones, and China one?  You will! Oh, and the time on which computer is correct anyway?  What happens when they disagree? Don't even get me started on effectivity.  It makes regular date problems look like a runny nose.  We'll discuss that another time. I'm not saying it's easy to fix these issues.  What's easy is having a broken solution that works as long as you're in one calendar, one time zone, one jurisdiction. What's the real solution?  You need to consider what some 'date-time-like' value really is.  When will close of business happen over the next seven days?  Is it an absolute time?  Well, not really.  It's more like an offset.  Actually, practically any time describing the schedule for a future event is likely to be an offset from midnight.  Midnight of that day.  In that time zone.  According to daylight savings rules in effect.  As defined by the calendar of jurisdiction.  Predicted revolutions of the Jovian moons are rather more likely to be 'absolute' than "Poll opening on election day." Don't just breeze past those time values - think them through.  What does this time mean?  Does it repeat?  Is it in the future? Are you capturing the time correctly, normalized to UTC? How are you synchronizing time across servers? So how do you test this mess?  I have a hazy notion I'd like to try.  Automated testing could use a custom calendar to verify time-dependent operations, shifting the start date of the calendar to match the test period. For live ops, switch the calendar to Standard/Western or whatever calendar you are using. Any thoughts?