I've been browsing the JodaTime documentation, and it has partially answered a question that I've wanted to ask:
How do Dates compare across timezones? For example, Is 3rd March 2011 in Hong Kong (GMT+0800) equal to 3rd of March 2011 in PST (GMT-0800)? JodaTime only supports pure "Dates" as a LocalDate class, which has no Timezone information. In this case, 3rd March 2011 is 3rd March 2011. To further complicate matters, Java's own documentation for java.util.Date states that "Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine." The emphasis is that Java implicitly assumes that Date is based on UTC, and includes time information, so is really a DateTime class. So, to keep focussed: What should the role of oai.applib.value.Date be? Should it keep just the date? This seems to be it's purpose. Should it be timezone aware? What does this mean for comparisons? Likewise, for oai.applib.value.Time... Here, one could almost argue that timezones can be included, but what about daylight savings? If timezone information is included, then, in Britain, a time of 12h00 UTC occurs at 12h00 UTC in winter, but at 13h00 BST in summer? To me, 12h00 should occur at mid-day, irrespective of (for example) daylight savings or not. oai.applib.value.DateTime is unambiguous: It represents a moment, and can be timezone aware. Comparisons are meaningful (3rd March 2011, 12h00 GMT == 3rd March 2011, 14h00 SAST) In short, I would like to recommend moving over to something like the JodaTime paradigm: Date and Time are pure local representations, with no timezone (12h00 is 12h00, in London or Johannesburg, summer or winter, 25th December is 25th December, London or Johannesburg). DateTime has a timezone, which must be taken into account when comparisons are made. When comparing Date's and Time's with a DateTime, only the pure year/month/day or hour/minute/second values are used (which implicitly puts the Date or Time being compared into the DateTime's timezone). Recurring events are handled as either recurring DateTimes or Times that recur on repeating dates. They are different, so probably the latter! Apparently iPhones had an issue when recurring alarms went off an hour later once daylight savings kicked in. That's what happens if you recur a DateTime instead of a Time!
