× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.





Gary,

Thanks for the follow up. I checked QUTCOFFSET and , sure enough, it's set at
the shipped value of +00:00 ie. GMT. However, before setting to +01:00 (BST)
I'll check that it won't impact anyone else. The only downside to this is the
biannual manual adjustment.

I'm not sure but I suspect that the JVM time would adjust automatically and
correctly after having set the timezone to "Europe/London" AND with QTIME always
set to GMT. I also assume that the GMT/BST changeover dates are known for some
years to come and held somewhere within the JVM?  Ideally, I'd prefer this
option (if correct) but this is not possible since other applications require
QTIME to be adjusted between GMT and BST.

Regards,

Keith







"Gary L Peskin" <garyp@firstech.com> on 09/08/2002 09:35:27

Please respond to java400-l@midrange.com

To:   java400-l@midrange.com
cc:    (bcc: Keith McCully/Wunderman/GB)

Subject:  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

_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.









As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.