#7 Support for specifying timezones for date construction.

[James Styles]

MXPJ is constructing calendar objects using Calendar.getInstance(). This method uses the default timezone (ie. result of TimeZone.getDefaultTimeZone()). This can become an issue when the default timezone includes daylight savings and the project file being read crosses a dst boundary.

A quick hack to this issue is just to change the default timezone before using mpxj and changing it back after. However this could have undesirable side effects if anything else relies on the default timezone.

It would be preferable to be able to set which timezone MPXJ used for calendar/date construction - though even having it be guaranteed to use a DST-free timezone (ie. UTC) would be nice.

[James Styles]

Example MPP file crossing DST boundary

[James Styles]

MPXJTestCase showing DST issue

[James Styles]

Added a MPXJTestCase & MPP file showing the issue when the default timezone uses daylight saving time.

[Jon Iles]

Just doing some housekeeping to clean up old tickets.

I had a quick look at this one, the new unit test actually passes everything except the last test:

      // Check the elapses hours in Java is 24 hours.
      elapsedHours = (finishDate.getTime() - startDate.getTime()) / MILLISEC_PER_HOURS;
      assertEquals(24, elapsedHours);

Although MS Project reports the task as having 24h duration (even when the timezone of the PC is set to Pacific time), the "real world" duration is 23 hours as we're transitioning into DST. It looks like MS Project is ignoring DST transitions for duration calculations, but performing arithmetic with the raw timestamps themselves in Java is always going to give us a correct "real world" value rather than matching what MS Project is doing.

Looking at the Date implementation I'm not sure we can achieve what the ticket asks for as Date itself seems to lean heavily on the default timezone (with no way to supply a specific TimeZone for a Date instance. . I think we'd need to pass around Calendar to get the desired result.

I will be looking at this area again in future with an eye to using the improved Joda/Java 8 date/time types.