Matthew wrote: >if not, add 1 week to event start. loop until current time is less than >new event start and return new event start.
If you're doing this in the local timezone, it is better to add N weeks to the original event time (and increment N) than to add 1 week onto the previous event time. This minimises funny behaviour around DST changes. >But when you throw in the adding of weeks to an original start date, >should the orig start date be in local TZ or GMT? The customer will most likely want events occurring at, say, 11:00 every Monday in their local timezone. For that you need to do the date arithmetic in the timezone; the gaps between events will occasionally be 167 or 169 hours instead of the regular 168. Some customers might want events at 168-hour intervals regardless of timezone; you could cater to that by giving them the option to specify an event in GMT instead of their actual timezone. You can handle both cases, therefore, with just the local timezone logic. -zefram
