Daylight Savings Time (DST) - Sun JVM Upgrade Question

I am using JRun 4 Build 106363 on a MS Windows 2000 Server.
We have updated our Windows 2000 server for the new DST. I also
updated Sun j2sdk1.4.1_02 using Sun Java SE TZUpdater Tool.
Do I have to upgrade to Sun's JVM version 1.4.2_11 (see link
to technote below) or will the steps I've already taken ensure
correct DST date/time handling?
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=d2ab4470

You need to upgrade to 1.4.2_11.
Ted Zimmerman

Similar Messages

Daylight Savings Time (DST)

Hi,
Can any body tell me what is Daylight Savings Time (DST)? What is its significance in Java?
Nischal

nrlz is of course pulling your leg (sorry to ruin your fun nrlz). DST is the system wherein clocks are set forward an hour in the spring and back an hour in the fall. It's significant in Java if you need to model it in your Java application.

Daylight Savings Time (DST) fix in firmware

Yet another DST time has come and gone (well, not really, in that the router WRT54G thinks that time changed last weekend when it doesn't actually change until THIS weekend) with no firmware update for the new (well, not really, it's old now) legislation.

You will find that Linksys equipment is ok. But remember it's not professional equipment. You get what you pay for and the support proves it.

Australia 2008 Daylight Savings Time DST Changes

Lasy year some Australian states changed the Date that DST is ended, from 30th March to the 6th of April:
See for details: http://www.lawlink.nsw.gov.au/lawlink/cru/ll_cru.nsf/pages/cru_daylightsaving
I can find patches for the 2006 change made to accomodate the commonwealth games, but can not find patches for the changes that come in to effect 2007-2008.
Anyone know where these can be found (I assume they exist).
Thanks in advance,
John

The JDK download page has a timezone updater that you can download. Each new Java version contains updates to the tz rules, your version may already include what you want.

Has anyone had problems in v5.0a of Iplanet calendar installed on a Sun box with creating events and daylight savings time?

Events created around 4/6/2002 at 8pm get created with the wrong time (9pm) and there are several other creation and display problems tied to Daylight Savings in April and October. Version 5.1 of the software seems to fix that but we are looking for a fix until we can upgrade. We have been using Windows systems to access the calendar.
Thanks.

We have not seen exactly this, but many users appointments are lining up in the wrong time slots. Also, when scheduling, the time display is off by an hour. We have found what looks like a temporary fix.
We noticed that the problem only affects users who have the start of the week set to Sunday (when daylight savings time started). Setting the week to start on Monday fixed our display problems (you can do it in the users, options section).
I am placing a support call w/SUN.

Daylight Savings Time 2007 - firmware upgrade ?

In 2007 the start and end dates are going to be different for Daylight Savings Time. As a result, servers are going to need to be patched. Here is a related link I came across:
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102617-1
My question is, how do I know whether or not my firmware (PROM) needs to be updated too ? I have searched and have not found a lot of information on the topic of the firmware. Does anyone have any good links or pertinent information on whether the firmware would need to be updated or not ? I have several Netra T1's, Sunfire V480's, and my Sunblade 100 workstation that I am concerned about. Here is the OBP level from one of my V480's that is on Solaris 8: OBP 4.6.8 2002/09/04
and here is the OBP from a V480 on Solaris 9: OBP 4.10.14 2003/11/19.
Thanks for any information.

The platforms mentioned in the Sun Alert 102617 that you linked above,
are all Sun Fire Midrange Server systems.
Their "firmware" is a part of a completely different sort of of architecture.
Their system controllers are a tiny computer, with its own OS, inside the Sun Fire system.
That Real Time Operating System (RTOS) that runs on the SC's has its own
time-of-day function that is independant of whatever Solaris gets installed
to whichever domain or domains you configure to the computer.
Thus the need for the Sun Alert, separate from any TOD discussion for Solaris..

10.3.9 Daylight Savings Time Problem (DST Patch applied), it was working

We have about 30 Macs running 10.3.9, all of which were patched last year with the DST patch (2007). They are all configured to set the date and time automatically using time.apple.com. The user account used by the people using them is a non-administrator account.
Since Daylight Savings Time changed in March 9, 2008, they correctly changed their time until late last week (end of March), when several of them went back to the old time. If I open the Date & Time System Preference Pane and authenticate, the clock changes to the correct time, without any further input from me other than authenticating as the admin. Once changed, some but not all go back to the incorrect time about a day later.
Any ideas? I am trying to see if there is a simpler solution that resetting PRAM, throwing away cache files, etc.
Other machines running newer versions of the OS don't have the issue.
Thanks in advance for any input and/or advice.

hypermouse1, welcome to Apple Discussions.
How long has it been since you changed the internal memory battery? Check this site for battery part numbers and sources.
Mac PRAM, NVRAM, CUDA/PMU & Battery Tutorial
http://www.geocities.com/texas_macman/pram.html
 Cheers, Tom

DST-2007 Daylight Savings Time Patches for MAC OS

I have found Daylight Savings Time patches for other platforms.
Is there a patch for Daylight Saving Time for MAC OS?
Thanks.
Bev

markpb91 wrote:
Coffs Harbour, northern NSW along the coast. So I'm on Sydney AES time.
Beautiful part of the world! I have under Date and Time in System Preference marked as such
Date and Time    South Asia (have set automatically unticked)
Then Time Zone set for Australian Eastern Daylight saving time
                                   Melbourne - Australia    (I'm in Ballarat)
                                   With set time automatically up the top unticked
They are the settings I have always used and my computers have always reverted to and from Daylight savings (except of course I'm in Queensland, Then I have to reset my location and remember to set it back.
Other than that if may come down to trashing your pref file for date and time.
Good Luck

IdM Scheduler and Time Change to Daylight Savings Time GMT to BST

This isn't really a 'question' , but just a topic for discussion.
We're not live yet, but will be by the time the clocks go back. So I'm just interest to hear everyone's experiences and any issues with regards to the switching to / from DST
I did some "interesting" (or not) tests last night to see what happens with Pending Values which are due to take effect at the time change threshold of 01:00 GMT when switching to Daylight Savings Time (BST) GMT +0100.
It seems as if the IdM scheduler keeps going according to UTC or GMT. However any values provisioned to target systems or to local tables using the ddm.datetime8601 system variable are in local time according to the runtime server or SQL server's locale settings.
I set up a task to output from a javascript the current system date
using the following in the functions.
currentTime = new Date();
return currentTime.toString(); // returns Locale Time String
currentTime = new Date();
return currentTime.toUTCString(); // returns UTC Time String
in the same pass I also output the ddm.datetime8601 system parameter and the ddm.time24 system parameter.
This task was to update a comment on an entry and Scheduled to run at 00:00:00 and was executed at 00:00:06 GMT all times were still in GMT as expected.
Local Time: Sun Mar 27 00:00:06 GMT-0000 (GMT) 2011, UTC Time: Sun, 27 Mar 2011 00:00:06 GMT, ddm.datetime8601: 2011-03-27T00:00:06, ddm.time24: 00:00:06
This task was scheduled at 01:00:00 in IdM and was exectued at 01:00:08 GMT by the runtime, and you can see the local time is being correctly reported as 02:00:08 BST. Note also the ddmdatetime8061 is also 02:00:08 i.e. BST.
Local Time: Sun Mar 27 02:00:08 GMT+0100 (BST) 2011, UTC Time: Sun, 27 Mar 2011 01:00:08 GMT, ddm.datetime8601: 2011-03-27T02:00:08, ddm.time24: 02:00:08
In the database the entry values MXI_VALUES ModifyTime field has the GMT / UTC timestamp.
I also set up some pending value objects to be applied at 00:59:59 and 01:30:00 to see if the 01:30:00 would be 'skipped' as the locl clock change would've gone from 00:59:59 to 02:00:00. Well the pending values were correctly applied and expired and no 'lost' transactions happened as a result of the change.
So essentially it seems to me that the IdM runtime and scheduler times are all based on UTC / GMT.
I guess it's only an issue twice a year if you're expecting something to happen at a specific local time 01:00:00 or if you've got a global user base and their account expiry should be in each user's own country's local time. In these cases, it would seem that you'd need to convert the schedule times and pending value times to UTC first before setting them in the database.
Has anyone else had any issues, thoughts, questions or suggestioins on scheduling tasks which span the DST time change when switching to and from Daylight Savings Time.
Edited by: Paul Abrahamson on Mar 27, 2011 10:51 AM

Read here:
http://www.appleinsider.com/articles/10/10/11/applesays_ios_software_update_to_fix_pesky_alarm_clockbug.html

E-Load/e-ME and Daylight Savings Time Change

If you are using e-TEST suite versions 8.10 or older, please see the following knowledge base article on updating your JRE for e-Load and e-Manager Enterprise.
http://qazone.empirix.com/entry.jspa?externalID=201&categoryID=15
(you must be logged into QAZone to view this link)
It is recommended that e-Load and e-Manager Enterprise customers update the JRE on their e-Load and e-ME server machines using the SUN JRE patch referenced in the article.
e-TEST suite version 8.20 which is releasing this week does not require any update.
Message was edited by: jfernandes

My problem is that now CFMX 6.1 thinks that it is 8 hours
later in the day
than it really is (it is stuck on GMT now) and I am unable to
get CFMX to
acknowledge the operating systems clock. :-(
"GregK" <[email protected]> wrote in message
news:eord35$5mq$[email protected]..
The technote for this issue:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=d2ab4470
has
another
link to a technote which addresses null pointer exceptions
after upgrading
the
JVM on CFMX 6.1 systems:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb400232
The hotfix
described in that technote gives a fix for CFLDAP and
CFSERVLET tags after
the
new JVM is installed.
The important thing to note is that Adobe feels that
daylight savings time
will indeed present a problem for ColdFusion applications.
Unfortunately,
the
problems are not explained in any detail. I can guess that
functions like
DateDiff( ) may calculate incorrect values when spanning the
changed weeks
of
daylight savings time. As others have suggested; however,
simply retrieving
the system time, i.e. Now( ) function may not be affected as
long as the
operating system clock is set correctly.
Hope that helps.

JRE Update regarding Daylight Savings Time changes

Hi,
Is there a JRE Update to be released anytime soon dealing with the US Daylight Savings Time changes?
A similar update was released for the DST changes in Australia (JRE 1.5.0 Update 6). The link to information page is:
http://java.sun.com/developer/technicalArticles/Intl/AusTimeZone/
If there is an update coming for US, when would it be?
Thanks,
Vinay.

If you had read through the bugs related to the one
whose link was in the post just before yours, you
would have seen this one:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=639
1777
which appears to answer your question.If I read the bug report right, a fix was made to JDK 1.3.1 to handle the Australia situation. Are you pointing me to the workaround or a potential fix for the US timezone issue?
The bug report says: "This fix is based on tzdata2006a." Does this tzdata file include an entry for the March 2007 onwards change in the US?
-Raj

Energy Act of 2005 and Daylight Savings Time

We currently use Sun Studio compilers. We use the embedded tools.h RogueWave libraries. The Energy Act of 2005 changes the dates for Daylight Savings Time starting in 2007. Will there be any patches from Sun to handle this? We currently use RWZoneSimple which is extensible, but we were hoping for an update from Sun.
Thanks in advance. Sorry if this has been covered, I just couldn't find anything.
Further Reading:
http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005

The RW Tools.h++ library that comes with Sun Studio has been updated with the new DST rules. I don't think the patches have been released yet.
If you have a service contract with Sun, you can get a pre-release version of the patch via your support channel.
Otherwise, check the Sun Studio patch page from time to time
http://developers.sun.com/sunstudio/downloads/patches/index.jsp
Look for a C++ compiler patch that includes a fix for bug 6456479.
RW Tools.h++ does its own DST calculations. Other libraries rely on the Solaris functions in libc. Patches for Solaris are available now as follows:
S10 - 118833-24(sparc), 118855-19(x86)
(The fix is included in S10u2.)
S 9 - 112874-34(sparc), 114432-24(x86)
S 8 - 108993-62(sparc), 108994-62(x86)

CF MX and Daylight Savings Time Change

Next year 2007, the Daylight Saving day (chaning the clocks
for spring and fall) will be changing. The Spring date will be a
month earlier and the fall date a month later then it has been for
years.
How will the Cold Fusion Server for MX 7+ handle this? Will
it use the server time or use the internal CF Server clock?
Thanks.

My problem is that now CFMX 6.1 thinks that it is 8 hours
later in the day
than it really is (it is stuck on GMT now) and I am unable to
get CFMX to
acknowledge the operating systems clock. :-(
"GregK" <[email protected]> wrote in message
news:eord35$5mq$[email protected]..
The technote for this issue:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=d2ab4470
has
another
link to a technote which addresses null pointer exceptions
after upgrading
the
JVM on CFMX 6.1 systems:
http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb400232
The hotfix
described in that technote gives a fix for CFLDAP and
CFSERVLET tags after
the
new JVM is installed.
The important thing to note is that Adobe feels that
daylight savings time
will indeed present a problem for ColdFusion applications.
Unfortunately,
the
problems are not explained in any detail. I can guess that
functions like
DateDiff( ) may calculate incorrect values when spanning the
changed weeks
of
daylight savings time. As others have suggested; however,
simply retrieving
the system time, i.e. Now( ) function may not be affected as
long as the
operating system clock is set correctly.
Hope that helps.

Daylight Savings Time Conversion correction.

I have a question. Will I need to make the following correction each year after/belore daylight savings time?? If so, is there a way to make this change programmatically?
http://digital.ni.com/public.nsf/allkb/95CA7D76758B736B8625777C006C7934
Thank you, John

Look at the Date/Time to Seconds function and its inverse. It uses a cluster to get a timestamp or visa versa. This will help you tell if DST is used. If you have a timestamp already, I'm pretty sure LabVIEW accounts for DST already. But use these functions to make sure.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

SimpleDateFormat / Daylight Savings time issue in 1.5.0_11 ?

I am having trouble with SimpleDateFormat.format(), possibly due to Daylight Savings Time, but I can't figure it out.
      import java.text.*;
      import java.util.*;
      public class Test {
        public static void main(String[] args) throws Exception{
          SimpleDateFormat dateFormat = new SimpleDateFormat("EEE MMM dd z yyyy");
          Date date = dateFormat.parse("Tue April 13 CDT 2007");
          System.out.println(dateFormat.format(date));
          System.out.println(date.toString());
          SimpleDateFormat dateFormat2 = new SimpleDateFormat("MMMM dd, yyyy");
          System.out.println(dateFormat2.format(date));
      }I am in the CDT time zone.
If I run this code on JRE 1.5.0_04-b05, I get:
Fri Apr 13 CDT 2007
Fri Apr 13 00:00:00 CDT 2007
April 13, 2007This is what I expect. But, if I run this code on JRE 1.5.0_11-b03, I get:
Fri Apr 13 CDT 2007
Thu Apr 12 23:00:00 GMT-06:00 2007
April 12, 2007I don't understand why, the time calculated to be an hour off, since my time zone and locale are the same as that of the input string?
I thought this could be a DST issue, but a) both dates are in DST, and b) I tried applying the fix to the Java 5 DST bug, on the off chance it would help. but it did nothing. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6530336
I'm stumped. Can anyone help?
Thanks,
Ed

It looks like the problem is that Java doesn't have my timezone correct after all.
SimpleDateFormat dateFormat = new SimpleDateFormat("EEE MMM dd z yyyy");
System.out.println(dateFormat.getTimeZone());    prints:
sun.util.calendar.ZoneInfo[id="GMT-06:00",offset=-21600000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
...which is wrong. It should be dstSavings=3600000,useDaylight=true.
So, one SimpleDateFormatter has CDT as its timezone, and the other has CST as its timezone. This changes the time from midnight on one day to 11 pm on the previous day, causing the wrong date to be shown.
This workaround gives the date I want, the original date at its (not my) timezone.
    SimpleDateFormat dateFormat = new SimpleDateFormat("EEE MMM dd z yyyy");
    Date date = dateFormat.parse("Tue April 13 CDT 2007");
    SimpleDateFormat dateFormat2 = new SimpleDateFormat("MMMM dd, yyyy");
    dateFormat2.setTimeZone(dateFormat.getTimeZone());
    System.out.println(dateFormat2.format(date));Now if I can coerce Java to give me my correct local time zone, I'll be set.

Daylight Savings Time (DST) - Sun JVM Upgrade Question

Similar Messages

Maybe you are looking for