Bill Moseley wrote: >Again, developers of varying skills come and go and work on existing code. > So, they may not have any idea that "$start_time" has a timezone or think >about DST issues. Or that a day isn't always 24 hours.
So teach them. If they're going to be working a lot in this problem domain, they ought to learn enough about it to avoid making basic errors. >What if DatTime Duration objects had a flag to say do the math in UTC? > Would that avoid the problem if it possibly failing? That would make the issue of what a DateTime::Duration actually represents even more confusing than it already is. >In my experience the floating times open up other headaches. We store all >times with a timezone -- we would rarely have something like "9am your >time" because of the ambiguity. I'm not suggesting that *you* forget which timezone applies. I'm suggesting that you do the date arithmetic without telling *DateTime* to apply a timezone. Do the date arithmetic in "floating" timezone, and store the resulting local time along with the timezone name. To compare the current time against this stored threshold, take the current time, express it in the stored timezone, then take the resulting current local time and compare that (sans timezone) against the stored local time. -zefram
