RE: JavaMail API: SentDate problem

Keith --

You might want to check QUTCOFFSET as well. It's supposed to be set to
the offset from GMT so in your case that would be
+1.  QTIME is supposed to be set to the local time and QUTCOFFSET to the
current GMT offset.  I think this could fix your problem.

You'll need to remember to change QUTCOFFSET back to zero when you go
off of Summer Time.

Also, I'm not sure what else this will affect.  The Work Management book
says it's used for intersystem time reconciliation but I'm not sure who
else your 400 is connected to.

If you have a test box available, it might be worth fiddling with.

Gary

> -----Original Message-----
> From: java400-l-admin@midrange.com
> [mailto:java400-l-admin@midrange.com] On Behalf Of
> Keith_McCully@wunderman.co.uk
> Sent: Wednesday, August 07, 2002 6:54 AM
> To: java400-l@midrange.com
> Subject: RE: JavaMail API: SentDate problem
>
>
>
>
>
> I have added user.timezone=Europe/London to the file
> SystemDefault.properties in /QIBM/UserData/Java400.
>
> I tried:
>
> Calendar z = new GregorianCalendar(TimeZone.getDefault());
> System.out.println(z.getTime().toString()); // current date/time
>
> getting: Wed Aug 07 15:05:02 GMT+01:00 2002. So the time zone
> portion is now correct (BST = GMT+01:00) although the actual
> time is now 1 hour ahead. Request time was 14:05:02. It seems
> as if the JVM assumes the base time for the zone is without
> daylight saving (GMT in my case) and then the daylight
> adjustment is applied on top. However, since our AS/400
> system time (QTIME) has already been adjusted for BST an
> extra hour has been added. There's no way I'll set QTIME to
> GMT due to the massive impact elsewhere! Instead I'll go for
> a workaround since the time zone part is now correct. The
> current date can be tested for daylight saving in effect by
> using the inDaylightTime method for the default TimeZone.
>
> Regards,
>
> Keith