Clock UI control and daylight saving time.

Hi,
We have a customer that has several sites around the world.
In a VC-model I like to use the Clock UI control to display the times of the different sites.
This can be done by setting the ‘time zone’ in the control properties.
A long ago we have introduced ‘daylight saving time’.
It seems that the clock control does not do anything with this ?
How can I change the time zone when the model is running ?
Can it be done by an expression and how ?
There is also a problem of the country, some have DST, others don’t.
See http://en.wikipedia.org/wiki/Daylight_saving_time_around_the_world
Example:
I have 2 clocks and the end-user lives in Amsterdam:
Amsterdam, time zone = GMT + 1
Santiago, time zone = GMT – 4
During the winter in Amsterdam it is summer in Santiago and has ‘daylight saving’ so the time in Santiago should be GMT – 3 in stead of GMT -4.

With the current version of VC / flash, it is not possible to display the correct time all the year 'round.
If you only want to show the (user) current time then you can use this VC clock object.
If you need to show clocks from different cities around the world, than its better NOT to use the VC clock.
Because you can not define the country and city in the clock properties, that determine the use of DST, it will not always show the correct (default / DST) time.
Solution:
Add a HTLM-view to your model with a links to a web clock.
Nice (free !) clocks can be found (and customized) on <a href="http://www.worldtimeserver.com/clocks/wtsclock001.aspx">worldtimeserver.com</a> or <a href="http://www.timeanddate.com/clocks/free.html">timeanddate.com</a> .
Example:
For the city Santiago (Chile) the URL =
http://free.timeanddate.com/clock/ielrw91/n232/tluk/fn13/fs16/fc009/tt0/tw1/td2/th1/ts1/tb4

Similar Messages

  • Oracle WebLogic Server (WLS), Time Zones, and DayLight Saving Time (DST) Changes

    Hello,
    We are approaching this time of the year again...
    I would like to redirect you to the Support Note 1370083.1 "Oracle WebLogic Server (WLS), Time Zones, and DayLight Saving Time (DST) Changes"
    This note lists what is to be expected from WebLogic Server regarding this time change period, in terms of behavior, both for the engine and the applications deployed onto WLS.
    Regards,
    Patrick.

    Probably this:
    http://www.jdocs.com/castor/0.9.5.3/api/org/exolab/castor/xml/handlers/DateFieldHandler.html

  • Java 1.4 and Daylight Saving Time 2007

    The current version of Java 1.4.2 for Tiger, 'Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-244)' does not handle the new 2007 Daylight Saving Time rules correctly. Will Apple be updating Java 1.4.2 to the version that does support 2007 DST correctly? (at least 1.4.2_11 is required per Sun, http://java.sun.com/developer/technicalArticles/Intl/USDST/).
    If so, when? Thanks!

    Since you didn't list your computer, here's a link to Java 5.0 release 4 for both PPC and Intel-based Macs, which came out in April: http://search.info.apple.com/?q=J2SE50Release4.dmg&type=kbdload&search=Search&lr =lang_en&search=Go. That should solve your problem.

  • TimerThreads and daylight saving time

    I have this task that I need to do everyday at 0:00 AM.
    I am using the ScheduleAtFixedRate method to perform this starting it at 0:00 AM and running it again every 24 hours. It is very important to run at 0:00 because it involves money a a reconciliation file.
    According to the API documentation:
    Fixed-rate execution is appropriate for recurring activities that are sensitive to absolute time, such as ringing a chime every hour on the hour, or running scheduled maintenance every day at a particular time.
    My question is what about daylight-saving time ? What happens to such a task that is supposed to run every day at 0:00 ?
    Thanks
    Luis Cordeiro

    My guess, and it is just a guess, is that the task will run every 24 hours, and therefore after a daylight saving time switch you will find it running at 01:00 or at 23:00. But I would suggest you test for yourself. Set up a test program that schedules a task every 3 hours, change your system's date and time to be 5 hours before the end (or start) of DST, and see what happens after it runs for 6 hours.

  • TimeZone getDisplayName and Daylight Saving Time

    Hi all,
    Is this a good way to get "CST"/"CDT" accurately?:
    // Determine whether or not we're in Daylight Saving Time
    // (affects the CST/CDT/etc. printing in the output).
    boolean isDst = false;
    if (cal.get(Calendar.DST_OFFSET) != 0) {
         isDst = true;
    Thanks so much :-)

    I'd use one of the TimeZone methods, for instance inDaylightTime(date); one of the other DST methods may work better for you.

  • Castor and Daylight Saving Time 2007 Changes

    Hi,
    Can anyone tell me if Castor will be affected by the changes to Daylight Saving Time (DST) in the US in 2007?
    Thanks

    Probably this:
    http://www.jdocs.com/castor/0.9.5.3/api/org/exolab/castor/xml/handlers/DateFieldHandler.html

  • Problem with SLQ Date and Daylight Saving Time

    Hi everybody!
    It seems, that when I have a date in the database, which falls on start of the daylight saving period, it is converted to the previous date.
    Example: '2001-10-13' will become '2001-10-12' after doing a date = rs.getDate() and then converting back using date.toString().
    This caused a lot of trouble because the date value is part of an unique key constraint!
    Currently I wrote a wrapper method, which obtains the date as string and converts this one into a date by setting the hours to 12:00.
    Does anybody know a straighter way to avoid the conversion?

    Because the default time zone is using day light saving time. To remove this feature, reset your default time zone at the very beginning of your program:
    TimeZone.setDefault( new SimpleTimeZone( TimeZone.getDefault().getRawOffset(), TimeZone.getDefault().getID() );

  • TS1638 When syncing calendar on iPhone with Microsoft Office whole day appointments get moved to double day. I am aware this may be caused by conflicts in clock, viz daylight saving time. However, Outlook seems OK and takes time from Windows time and zone

    When syncing my iPhone to Microsoft Outloook all the full day appointments become two day - 2300hrs to 2300hrs next day. Sometimes this will include a nuber of a single day of 23 hours. Looked at solutions and all point to a clock issue or a daylight saving and winter times. Outlook operating time is directly from the Windows clock that incudes the change of times for daylight saving etc. It is set for UTC Dublin, Edinburgh, Lisban, London with daylight saving included in the options. I can't see what I can do.

    When syncing my iPhone to Microsoft Outloook all the full day appointments become two day - 2300hrs to 2300hrs next day. Sometimes this will include a nuber of a single day of 23 hours. Looked at solutions and all point to a clock issue or a daylight saving and winter times. Outlook operating time is directly from the Windows clock that incudes the change of times for daylight saving etc. It is set for UTC Dublin, Edinburgh, Lisban, London with daylight saving included in the options. I can't see what I can do.

  • IPod clock and daylight savings time...

    I've missed a lunch appointment today because of my iPod!! It looks like a bug to me.
    I arrived in SFO from South Africa and used my iPod clock this morning - it turned out to be an hour slow. When I looked at the clock, I saw that 'daylight saving' was turned off. This seems to be the default if you add a new clock.
    Why on earth would anybody want to have the wrong time when they create a new clock for a new city???
    Has anybody else seen this bug?
    I have checked the 'settings' section and there I had daylight saving turned on, so I don't think this should have happened.

    I think that you're telling me that the bug is worse than I thought!!
    Yes, daylight saving is artificial (all time measurement is, but that's another matter). That isn't the point, though. When I add a new city clock it is because I'm likely to be going there soon, or talking to somebody there, and I want the time to be correct. I have no idea if the place has, or has not, DST, and I don't care - I just want the clock to know and get it right.
    I think you're telling me that the iPod clocks don't download DST tables periodically to make sure that they have them correct (because they change from time to time).
    This means that the iPod clocks are not just useless, but dangerous. There ought to be a warning on the iPod saying - don't use this clock for anything you rely on because it may not know the correct time!!!
    I do hope you are wrong. Surely the clocks check and download the tables every time you connect to iTunes - surely!! Nobody could have been so irresponsible as to offer clocks that don't actually work...

  • The Daylight Saving Time to add 1h to clock in egy...

    the Daylight Saving Time to add 1h to clock in egypt ( Has been Canceled )
    the problem now all nokia phone automatic add + 1h to the clock but the the Daylight Saving is  Canceled in egypt  !!!
    the problem in
    nokia 6600
    nokia 6260
    nokia 5800
    nokia n97 mini
    nokia n97
    all nokia problem
    any help to solved this problem ?

    I live in Egypt and have this problem too.
    I hope Nokia provide a patch for that problem very soon.
    My phone model is Nokia N73
    OS version: 4.0839.42.2.1

  • Conversion mapping is losing time zone data during daylight saving time

    We have a problem with conversion of Calendars to timestamp with timezone for the last hour of Daylight Saving Time (e.g. 01:00 EDT - 01:59 EDT) where it is being interpreted as Standard Time which is in reality 60 minutes later.
    We've written a JUnit test case that runs directly against TopLink to avoid any issues with WAS and its connection pooling.
    The Calendar theDateTime comes from an object called TimeEntry which is mapped to a TIMESTAMP WITH TIMEZONE field using conversion mapping with Data Type TIMESTAMPTZ (oracle.sql) and Attribute Type Calendar (java.util).
    We are using:
    Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build Patch for Bugs 5145690 and 5156075)
    Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
    Oracle JDBC driver Version: 10.2.0.1.0
    platform=>Oracle9Platform
    Execute this Java:
    SimpleDateFormat format = new SimpleDateFormat("MM/dd/yyyy HH:mm z");
    TimeZone tzEasternRegion = TimeZone.getTimeZone("US/Eastern");
    Calendar theDateTime = Calendar.getInstance(tzEasternRegion);
    theDateTime.setTime(format.parse("10/29/2006 01:00 EDT"));
    Persist to the database and execute this SQL:
    SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    FROM time_table WHERE time_table_id=1
    This provides the following results:
    THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EST -5
    The wrong time zone is in the database. It should be EDT -4. Let's test the SQL that should be generated by TopLink. It should look like the following.
    Execute this SQL:
    UPDATE time_table SET the_date_time = TO_TIMESTAMP_TZ('10/29/2006 01:00 US/Eastern','mm/dd/yyyy HH24:MI TZR') WHERE (time_table_id=1)
    SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    FROM time_table WHERE time_table_id=1
    This provides the same results:
    THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EST -5
    Now, execute this SQL:
    UPDATE time_table SET the_date_time = TO_TIMESTAMP_TZ('10/29/2006 01:00 EDT US/Eastern','mm/dd/yyyy HH24:MI TZD TZR') WHERE (time_table_id=1)
    SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    FROM time_table WHERE time_table_id=1
    This provides better results:
    THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
    29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EDT -4
    The correct time zone is now in the database. Let's test reading this with the following Java:
    System.out.println("cal= " + theDateTime);
    System.out.println("date= " + theDateTime.getTime());
    System.out.println("millis= " + theDateTime.getTimeInMillis());
    System.out.println("zone= " + theDateTime.getTimeZone());
    This provides the following results:
    cal= java.util.GregorianCalendar[...]
    date= Sun Oct 29 01:00:00 EST 2006
    millis= 1162101600000
    zone= sun.util.calendar.ZoneInfo[id="US/Eastern",...]
    The TimeZone object is correct since we are using the US/Eastern regional time zone, but the millis are wrong which makes the time EST instead of EDT. The millis should be 1162098000000.
    The conversion from java.util.Calendar to TIMESTAMPTZ loses the actual offset when setting to a regional time zone. It can maintain this info by specifying it explicitly.
    The conversion from TIMSTAMPTZ to java.util.Calendar also loses the actual offset even if the correct offset is in the database.
    Has anyone else encountered this conversion problem? It appears to be a conversion problem in both directions. I know that the Calendar is lenient by default and will assume Standard Time if time is entered during the repeated 1 o'clock hour at the end of Daylight Saving Time, but the Calendars we are using are explicit in their time, so this would be classified as data corruption.
    Nik

    Opened an SR. Looks like there is a problem with conversion either in TopLink or in JDBC.

  • Brazil Daylight Saving Time Problem

    In Brazil, we enter the summer time and my blackberry 9800 torch automatically work, but when I synchronized with the playbook, some problems arose.
    The time in the menu setting is correct, as you can see in this image:
    But the wrong time remains the main screen:
    Does anyone have the same problem and knows how to fix it?
    tks,

    It did not work.
    It is indifferent to select manual or automatic, the problem persists.
    I'm in Brazil and with the correct time zone, but we are on daylight saving time.
    On the menu setting time and date, the time is right, however, in early 1 hour on application clock and and late 1 hour on the main screen.

  • ActiveSync Calendar and Daylight Saving

    Israel moved to Daylight Saving time and now all meetings scheduled by someone on that timezone are one hour off.
    - Meetings look okay on Outlook or OWA
    - the iPhone clocks are adjusted to the time change.
    In addition to my other post on meetings not synchronized (http://discussions.apple.com/thread.jspa?threadID=1715532&tstart=0) , my calendar is completely useless...
    Any fix for that?
    Should I switch back to Windows Mobile to get my productivity back up?

    I'm having the same exact problem. I've tried disabling Calendar Sync, I've tried deleting the entire ActiveSync account profile and it's still not working. All of my meeting continue to arrive on my iPhone an hour later then the meeting actually takes place. Looking at Calendar within Outlook, everything appears fine. Definitely had this problem since DayLight Savings went into place.

  • Exchange Active Sync UTC Daylight Saving Time

    Color me a bit confused. I am attempting to write an IOS client application to communicate with Exchange ActiveSync and display calendar information. But I am seeing some conflicting information in the protocol docs when compared to what I am getting from
    Exchange. Either that or I am somehow misinterpreting one or the other.
    My intent is to save an appointment in my local database in Coordinated Universal Time and then have the UI read in the information and display it as appropriate to the local timezone. In this way an recurring appointment created before daylight saving time
    for Noon will still be at the same time of day in local time as an appointment created during daylight saving time for noon. But they are not.
    My understanding of the documentation is as such:
    In MS-ASCAL pdf section 2.2.2.40 (roughly page 34) it says for Start Time that : ...the value of this element is a dateTime data type as specified in MS-ASDTYPE section 2.3.
    Moving to MS-ASDTYPE section 2.3 (roughly page 7) the dateTime value is specified in the format of ISO-8601 and all dates are given in Coordinated Universal Time (UTC)
    Looking up coordinated universal time I see that UTC does not changed with the seasons as local or civil time does and therefore DOES NOT support daylight saving time. This makes sense, as DST is decidedly local and is ignored by many areas. You cannot know
    from the perspective of UTC whether or not to apply a DST offset without knowing what timezone and area the time represents, therefore no daylight saving time can be supported. Based on this information I should be able to just slap the dates into my database
    as they are and merely have the UI adjust itself to display them properly.
    However, as a tested I began seeing a divergence of an hour between the two appointments in the database before the UI has even read them. To confirm this I created two recurring appointments representing Lunch at 12 noon local time. One that starts on March
    1st 2014 (Standard Time) and one that starts on March 10th 2014 (daylight saving time) in the eastern timezone. This should be March X 2014 at 1700 hours in both cases should it not?
    In the WBXML/XML that I am receiving I am getting two different times. The appointment that starts during standard time gives me a start time of 20140301T170000Z. The appointment that starts after daylight saving time is in effect locally gives me 20140301T160000Z.
    The difference between the two times is 1 hour, which is the daylight saving time offset. It is my perception based on everything that I have read both in the microsoft protocol documentation and outside it that these two times should be the same and that whatever
    client that gets to display them should be the one putting the offset in place as needed. Noon local time is noon local time but local time is the province of the local municipality/timezone, not that of UTC.
    So my question is what exactly is going on here? Are the start/stop/date stamp date times in UTC or not. If they are in UTC, then why are they offset by an hour instead of being at the same time? Obviously outlook displays these correctly for local time,
    because both appear at noon. But in my case my database contains locally adjusted times instead of the UTC times I thought I was getting which is throwing off when those appointments appear in the UI.
    Can someone please clarify what's going on here and what I should be seeing?
    Thanks.
    E

    Thanks for the reply, however after doing what is said the problem still remains. I did not try the manual approach, because of the time that would take with calendars that change at least daily.
    I am running the latest update of ICal and IPod, you would think this would have been addressed with one of the updates to allow the sync to work correctly with 5th generation IPods.
    I am going to try and turn off day light savings time set the clock to a Central Time zone and see if that works, I do not cross time zones much, anymore.
    MacBook   Mac OS X (10.4.9)  

  • USA Residents:  Early Daylight Saving Time *Changes*.

    Apparently, a few folks are unaware of the changes & patch because for various reasons they do not check and/or use their Software Update Control Panel.
    http://docs.info.apple.com/article.html?artnum=305056 About Daylight Saving Time changes in 2007

    I have a similar issue where we cannot upgrade the jdk 1.1 without involving a lot of effort. If we keep the same old jdk, can someone tell me if use of Date and Calendar api will be impacted by the Daylight saving change.....provided the timezone is default and not explicitly set to EST. Also there isnt any timezone related buss logic.

Maybe you are looking for