|
On Mon, 16 Sep 2002, Dare wrote: > Ok! I think we have 2 proponents for the manual process while others watch > the thread, one can only assume that they favor one or the other. My > thinking revolves around the following: > > 1. How is this done on other application server platforms like HP, Sun > and the like where Unix of different flavors are used as the OS? FreeBSD schedules a batch job in the crontab (similar to doing a ADDJOBSCDE) which checks if the time zone needs to be updated, and if so it will update it. If you found that behavior undesirable, all you'd have to do is remove that entry from the crontab, so it wouldn't check for daylight savings time starting/ending, and therefore would not make any changes. > 2. Are there "daylight saving" problems on other servers that are not > OS400 based or do they manually change it? None of my non-OS/400 servers needs changing manually anymore. OS/400 is the only one -- and because of this, I sometimes forget to do it, causing times to be wrong for people. > 3. Thinking "out of the box", I will expect that the guys that work with > the internal code will take into consideration the issues with time overlap, > time calculations, > and others issues that might cause problem on the iSeries. Okay, but there's only so much they can do. Programs that expect time to go forwards, never backwards, will have problems if the time changes during their run. There's really very little that the "internals" people can do about that. IMHO, people should design their programs better. Especially if they expect it to run at 2:00. All they have to do is use GMT times, or at least check the QUTCOFFSET sysval when reading the clock. If your software takes QUTCOFFET into account, there shouldn't be a problem. But, the nice thing about having a scheduled job, the way FreeBSD does it, is that you can change it's schedule to not conflict with batch jobs if you're concerned about it. The way Windows does it isn't very good. But that's not unsusual for Windows.
As an Amazon Associate we earn from qualifying purchases.
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.