British Summer Time - OSX 10.5.8 - time didn't change

Hi there,
British Summer Time is in effect as of last night, when all clocks were supposed to go forward an hour. The time on my iMac is set to update automatically, and has been doing so for the past 5 years...except today. It has remained at GMT, so I've had to change it manually. Changing the setting to 'auto' changes the time back one hour again.
I know Apple has had problems with daylight savings time on the iPhone...but haven't heard of any issues for OSX. Is there a fix for this?
Thanks.

My Iphone and Mac both messed up their time after British summer savings time came in -
Eventually I discovered that the mac had moved my timezone city location to Ghana in Africa; once I relocated to London the auto time on mac was fixed.
On the IPhone, I found that updating the ios to latest version fixed it.

Similar Messages

  • Task reminders and British Summer Time (GMT +1)

    I have Ovi Suite 2.1.1.1 and an E71.
    When I sync tasks with a reminder from Outlook, the reminder on my phone is one hour later.  Schedule items sync at the right time.
    I have selected GMT +1.00 on the phone as the time zone. 
    Something has obviously gone wrong with the timezone calculation as the phone doesn't realise that the time passed in from Outlook is already in British Summer Time (GMT +1) and goes ahead and adds an hour. However, it doesn't add an hour for schedule events....????
    Ta,
    Ed.

    Yes, the same problem using a Nokia E72 in Hungary. Reminders in Outlook 2007 are 2 hours earlier than on the phone. Very irritating! I'm using OVI Suite 2.1.1.1 on Win 7 (64-bit).
    Any help around?
    Kristof

  • British summer time solution in Apple Mail

    Hi
    Is there a solution to mail showing day light saving rather than British summer time.
    The mail headers seem to be stamped with the correct time but the time received column in mail seems to add one hour, my system is set to the correct local time using the apple time server and local city is set to London.

    > This has only become a problem since I moved from entourage to Mail.
    Maybe you made the transition when the change to summer time took place, or maybe Entourage showed the sent date instead of the received date.
    If you tell Mail to show the Date Sent column, the date will appear “correctly” there as well, but that’s because in that case it gets the date from the Date header instead of from the latest Received header...
    so to clarify its our old quickmail server that is causing the problem?
    Yes.
    Do you no a work around
    Not sure what you mean. The solution is obviously to set the date & time correctly on that computer (including the time zone & daylight saving settings). A work around could be moving the clock back one our again so that the time at least corresponds to the wrong timezone and Mail displays it correctly after converting it to the right timezone.

  • Do I need to worry about British Summer Time ?

    As an example a simple 3 program chain job using a set up schedule which is set to run at 10:00 and 16:00 hours daily Mon-Sat
    [repeat_interval   =>   'FREQ=daily; BYHOUR=10,16; BYDAY=mon,tue,wed,thu,fri,sat']
    The default timezone is currently set to Europe/London.
    Schedule start_time is set to TRUNC(systimestamp).
    I would expect and want the job to kick off at the next instance of 10:00; then at 16:00 with this frequency being repeated daily whether we are in BST or not.
    Based upon the above default_timezone and start_date settings, will the job run at 11:00 and 17:00 in BST (April to October) and revert to 10:00 and 16:00 (November to March) ?
    If so, what are the default timesone settings to use and the correct start date
    [E.G.: TRUNC(systimestamp); dbms_scheduler.stime() or something like To_TIMESTAMP_TZ('04-OCT-2010 10:00:00','DD-MON-YYYY HH24:MI:SS') ] which will allow the job to run correctly at 10:00 and 16:00 ?
    Also what would happen to jobs which run over the changeover times from BST to non BST ?
    Any help would be appreciated.

    Thanks for the info. It has put me on the right track.
    The key appears to be setting the timezone in both the scheduler default timezone AND in the start date (of the job or of the schedule if using a named schedule). All our jobs are run off named schedules so re-setting the start date does not affect running jobs and will only come into effect on the next job run. So re-setting can be done with no down time. Here are the results of my testing:
    In order to prevent changes to scheduled times when BST cuts ober in March/October each year:
    1.     set scheduler default timezone to Europe/London
    2.     set job or schedule start date to include the default timezone.
         If this is not done, the correct scheduled run times will be dependent upon when the job is set up (in GMT or BST)
         I.E.      set up in GMT: times will be correct for GMT and 1 hour out in BST
              set up in BST: times will be correct for BST and 1 hour out in GMT
    --check scheduler default timezone:
    select DEFAULT_TIMEZONE from dba_scheduler_global_attribute;
    Attribute_Name               Value
    DEFAULT_TIMEZONE               Europe/London
    cutover dates for 2010:
    Sunday 28 March 01:00 GMT - Sunday 31 October 01:00 GMT (02:00 BST)
    Results for cutover GMT to BST: Sunday 28 March 01:00
    DECLARE
    --set repeat interval
    interval_string VARCHAR2(100) DEFAULT 'FREQ=DAILY;BYDAy=MON,TUE,WED,THU,FRI,SAT,SUN;BYHOUR=1,2,3,4,23,00';
    start_date TIMESTAMP with time zone;
    return_date_after TIMESTAMP with time zone;
    next_run_date TIMESTAMP with time zone;
    no_of_days PLS_INTEGER DEFAULT 40;
    BEGIN
    --set start_date to include timezone     
    --start_date           := to_timestamp_tz('25-MAR-2010 00:00:00 Europe/London' ,'DD-MON-YYYY HH24:MI:SS TZR');
    --set start_date to NOT include timezone     
    start_date := to_timestamp_tz('25-MAR-2010 00:00:00' ,'DD-MON-YYYY HH24:MI:SS');
    return_date_after := start_date;
    FOR i IN 1..no_of_days LOOP
    DBMS_SCHEDULER.EVALUATE_CALENDAR_STRING(
    interval_string
    ,start_date
    ,return_date_after
    ,next_run_date);
    DBMS_OUTPUT.PUT_LINE('next_run_date: ' ||to_char(next_run_date, 'DY DD-MON-YYYY HH24:MI:SS TZD TZH TZR'));
    --DBMS_OUTPUT.PUT_LINE('next_run_date: ' ||to_char(next_run_date, 'DY DD-MON-YYYY HH24:MI:SS'));
    return_date_after := next_run_date;
    END LOOP;
    END;
    Result:
    The offset is incorrect pre change at GMT (+01) and offset correct post change at BST (+01); resulting in times being 1 hour out;
    resulting in times being 1 hour out.
    next_run_date: THU 25-MAR-2010 01:00:00 +01 +01:00
    next_run_date: THU 25-MAR-2010 02:00:00 +01 +01:00
    next_run_date: THU 25-MAR-2010 03:00:00 +01 +01:00
    next_run_date: THU 25-MAR-2010 04:00:00 +01 +01:00
    next_run_date: THU 25-MAR-2010 23:00:00 +01 +01:00
    next_run_date: FRI 26-MAR-2010 00:00:00 +01 +01:00
    next_run_date: FRI 26-MAR-2010 01:00:00 +01 +01:00
    next_run_date: FRI 26-MAR-2010 02:00:00 +01 +01:00
    next_run_date: FRI 26-MAR-2010 03:00:00 +01 +01:00
    next_run_date: FRI 26-MAR-2010 04:00:00 +01 +01:00
    next_run_date: FRI 26-MAR-2010 23:00:00 +01 +01:00
    next_run_date: SAT 27-MAR-2010 00:00:00 +01 +01:00
    next_run_date: SAT 27-MAR-2010 01:00:00 +01 +01:00
    next_run_date: SAT 27-MAR-2010 02:00:00 +01 +01:00
    next_run_date: SAT 27-MAR-2010 03:00:00 +01 +01:00
    next_run_date: SAT 27-MAR-2010 04:00:00 +01 +01:00
    next_run_date: SAT 27-MAR-2010 23:00:00 +01 +01:00
    next_run_date: SUN 28-MAR-2010 00:00:00 +01 +01:00
    next_run_date: SUN 28-MAR-2010 01:00:00 +01 +01:00
    next_run_date: SUN 28-MAR-2010 02:00:00 +01 +01:00
    next_run_date: SUN 28-MAR-2010 03:00:00 +01 +01:00
    next_run_date: SUN 28-MAR-2010 04:00:00 +01 +01:00
    next_run_date: SUN 28-MAR-2010 23:00:00 +01 +01:00
    next_run_date: MON 29-MAR-2010 00:00:00 +01 +01:00
    next_run_date: MON 29-MAR-2010 01:00:00 +01 +01:00
    next_run_date: MON 29-MAR-2010 02:00:00 +01 +01:00
    next_run_date: MON 29-MAR-2010 03:00:00 +01 +01:00
    next_run_date: MON 29-MAR-2010 04:00:00 +01 +01:00
    next_run_date: MON 29-MAR-2010 23:00:00 +01 +01:00
    next_run_date: TUE 30-MAR-2010 00:00:00 +01 +01:00
    next_run_date: TUE 30-MAR-2010 01:00:00 +01 +01:00
    next_run_date: TUE 30-MAR-2010 02:00:00 +01 +01:00
    next_run_date: TUE 30-MAR-2010 03:00:00 +01 +01:00
    next_run_date: TUE 30-MAR-2010 04:00:00 +01 +01:00
    next_run_date: TUE 30-MAR-2010 23:00:00 +01 +01:00
    next_run_date: WED 31-MAR-2010 00:00:00 +01 +01:00
    next_run_date: WED 31-MAR-2010 01:00:00 +01 +01:00
    next_run_date: WED 31-MAR-2010 02:00:00 +01 +01:00
    next_run_date: WED 31-MAR-2010 03:00:00 +01 +01:00
    next_run_date: WED 31-MAR-2010 04:00:00 +01 +01:00
    Re-set start date to include timezone
    I.E.:
    start_date := to_timestamp_tz('25-MAR-2010 00:00:00 Europe/London' ,'DD-MON-YYYY HH24:MI:SS TZR');
    The offset is correct pre change at GMT (+00) and offset correct post change at BST (+01); resulting in correct running times.
    Note also the 1 hour jump on Sun 28th March from 00:00 to 02:00 which omits the 01:00 schedule which does not exist for that day.
    next_run_date: THU 25-MAR-2010 01:00:00 GMT +00 EUROPE/LONDON
    next_run_date: THU 25-MAR-2010 02:00:00 GMT +00 EUROPE/LONDON
    next_run_date: THU 25-MAR-2010 03:00:00 GMT +00 EUROPE/LONDON
    next_run_date: THU 25-MAR-2010 04:00:00 GMT +00 EUROPE/LONDON
    next_run_date: THU 25-MAR-2010 23:00:00 GMT +00 EUROPE/LONDON
    next_run_date: FRI 26-MAR-2010 00:00:00 GMT +00 EUROPE/LONDON
    next_run_date: FRI 26-MAR-2010 01:00:00 GMT +00 EUROPE/LONDON
    next_run_date: FRI 26-MAR-2010 02:00:00 GMT +00 EUROPE/LONDON
    next_run_date: FRI 26-MAR-2010 03:00:00 GMT +00 EUROPE/LONDON
    next_run_date: FRI 26-MAR-2010 04:00:00 GMT +00 EUROPE/LONDON
    next_run_date: FRI 26-MAR-2010 23:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SAT 27-MAR-2010 00:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SAT 27-MAR-2010 01:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SAT 27-MAR-2010 02:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SAT 27-MAR-2010 03:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SAT 27-MAR-2010 04:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SAT 27-MAR-2010 23:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SUN 28-MAR-2010 00:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SUN 28-MAR-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: SUN 28-MAR-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: SUN 28-MAR-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: SUN 28-MAR-2010 23:00:00 BST +01 EUROPE/LONDON
    next_run_date: MON 29-MAR-2010 00:00:00 BST +01 EUROPE/LONDON
    next_run_date: MON 29-MAR-2010 01:00:00 BST +01 EUROPE/LONDON
    next_run_date: MON 29-MAR-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: MON 29-MAR-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: MON 29-MAR-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: MON 29-MAR-2010 23:00:00 BST +01 EUROPE/LONDON
    next_run_date: TUE 30-MAR-2010 00:00:00 BST +01 EUROPE/LONDON
    next_run_date: TUE 30-MAR-2010 01:00:00 BST +01 EUROPE/LONDON
    next_run_date: TUE 30-MAR-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: TUE 30-MAR-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: TUE 30-MAR-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: TUE 30-MAR-2010 23:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 31-MAR-2010 00:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 31-MAR-2010 01:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 31-MAR-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 31-MAR-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 31-MAR-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 31-MAR-2010 23:00:00 BST +01 EUROPE/LONDON
    ===============================================================================================
    Results for cutover BST to GMT: Sunday 31 October 01:00 GMT (02:00 BST)
    DECLARE
    --set repeat interval
    interval_string VARCHAR2(100) DEFAULT 'FREQ=DAILY;BYDAy=MON,TUE,WED,THU,FRI,SAT,SUN;BYHOUR=1,2,3,4,23,00';
    start_date TIMESTAMP with time zone;
    return_date_after TIMESTAMP with time zone;
    next_run_date TIMESTAMP with time zone;
    no_of_days PLS_INTEGER DEFAULT 40;
    BEGIN
    --set start_date to include timezone     
    --start_date            := to_timestamp_tz('27-OCT-2010 00:00:00 Europe/London' ,'DD-MON-YYYY HH24:MI:SS TZR');
    --set start_date to NOT include timezone     
    start_date := to_timestamp_tz('27-OCT-2010 00:00:00' ,'DD-MON-YYYY HH24:MI:SS');
    return_date_after := start_date;
    FOR i IN 1..no_of_days LOOP
    DBMS_SCHEDULER.EVALUATE_CALENDAR_STRING(
    interval_string
    ,start_date
    ,return_date_after
    ,next_run_date);
    DBMS_OUTPUT.PUT_LINE('next_run_date: ' ||to_char(next_run_date, 'DY DD-MON-YYYY HH24:MI:SS TZD TZH TZR'));
    --DBMS_OUTPUT.PUT_LINE('next_run_date: ' ||to_char(next_run_date, 'DY DD-MON-YYYY HH24:MI:SS'));
    return_date_after := next_run_date;
    END LOOP;
    END;
    Result:
    The offset is incorrect pre change at BST (+01) and offset correct post change at GMT (+01); resulting in times being 1 hour out;
    resulting in times being 1 hour out.
    next_run_date: WED 27-OCT-2010 01:00:00 +01 +01:00
    next_run_date: WED 27-OCT-2010 02:00:00 +01 +01:00
    next_run_date: WED 27-OCT-2010 03:00:00 +01 +01:00
    next_run_date: WED 27-OCT-2010 04:00:00 +01 +01:00
    next_run_date: WED 27-OCT-2010 23:00:00 +01 +01:00
    next_run_date: THU 28-OCT-2010 00:00:00 +01 +01:00
    next_run_date: THU 28-OCT-2010 01:00:00 +01 +01:00
    next_run_date: THU 28-OCT-2010 02:00:00 +01 +01:00
    next_run_date: THU 28-OCT-2010 03:00:00 +01 +01:00
    next_run_date: THU 28-OCT-2010 04:00:00 +01 +01:00
    next_run_date: THU 28-OCT-2010 23:00:00 +01 +01:00
    next_run_date: FRI 29-OCT-2010 00:00:00 +01 +01:00
    next_run_date: FRI 29-OCT-2010 01:00:00 +01 +01:00
    next_run_date: FRI 29-OCT-2010 02:00:00 +01 +01:00
    next_run_date: FRI 29-OCT-2010 03:00:00 +01 +01:00
    next_run_date: FRI 29-OCT-2010 04:00:00 +01 +01:00
    next_run_date: FRI 29-OCT-2010 23:00:00 +01 +01:00
    next_run_date: SAT 30-OCT-2010 00:00:00 +01 +01:00
    next_run_date: SAT 30-OCT-2010 01:00:00 +01 +01:00
    next_run_date: SAT 30-OCT-2010 02:00:00 +01 +01:00
    next_run_date: SAT 30-OCT-2010 03:00:00 +01 +01:00
    next_run_date: SAT 30-OCT-2010 04:00:00 +01 +01:00
    next_run_date: SAT 30-OCT-2010 23:00:00 +01 +01:00
    next_run_date: SUN 31-OCT-2010 00:00:00 +01 +01:00
    next_run_date: SUN 31-OCT-2010 01:00:00 +01 +01:00
    next_run_date: SUN 31-OCT-2010 02:00:00 +01 +01:00
    next_run_date: SUN 31-OCT-2010 03:00:00 +01 +01:00
    next_run_date: SUN 31-OCT-2010 04:00:00 +01 +01:00
    next_run_date: SUN 31-OCT-2010 23:00:00 +01 +01:00
    next_run_date: MON 01-NOV-2010 00:00:00 +01 +01:00
    next_run_date: MON 01-NOV-2010 01:00:00 +01 +01:00
    next_run_date: MON 01-NOV-2010 02:00:00 +01 +01:00
    next_run_date: MON 01-NOV-2010 03:00:00 +01 +01:00
    next_run_date: MON 01-NOV-2010 04:00:00 +01 +01:00
    next_run_date: MON 01-NOV-2010 23:00:00 +01 +01:00
    next_run_date: TUE 02-NOV-2010 00:00:00 +01 +01:00
    next_run_date: TUE 02-NOV-2010 01:00:00 +01 +01:00
    next_run_date: TUE 02-NOV-2010 02:00:00 +01 +01:00
    next_run_date: TUE 02-NOV-2010 03:00:00 +01 +01:00
    next_run_date: TUE 02-NOV-2010 04:00:00 +01 +01:00
    Re-set start date to include timezone
    I.E.:
    start_date := to_timestamp_tz('27-OCT-2010 00:00:00 Europe/London' ,'DD-MON-YYYY HH24:MI:SS TZR');
    The offset is correct pre change at BST (+00) and offset correct post change at GMT (+01); resulting in correct running times.
    Note: no one hour jump on Sun 31st Oct
    next_run_date: WED 27-OCT-2010 01:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 27-OCT-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 27-OCT-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 27-OCT-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: WED 27-OCT-2010 23:00:00 BST +01 EUROPE/LONDON
    next_run_date: THU 28-OCT-2010 00:00:00 BST +01 EUROPE/LONDON
    next_run_date: THU 28-OCT-2010 01:00:00 BST +01 EUROPE/LONDON
    next_run_date: THU 28-OCT-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: THU 28-OCT-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: THU 28-OCT-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: THU 28-OCT-2010 23:00:00 BST +01 EUROPE/LONDON
    next_run_date: FRI 29-OCT-2010 00:00:00 BST +01 EUROPE/LONDON
    next_run_date: FRI 29-OCT-2010 01:00:00 BST +01 EUROPE/LONDON
    next_run_date: FRI 29-OCT-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: FRI 29-OCT-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: FRI 29-OCT-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: FRI 29-OCT-2010 23:00:00 BST +01 EUROPE/LONDON
    next_run_date: SAT 30-OCT-2010 00:00:00 BST +01 EUROPE/LONDON
    next_run_date: SAT 30-OCT-2010 01:00:00 BST +01 EUROPE/LONDON
    next_run_date: SAT 30-OCT-2010 02:00:00 BST +01 EUROPE/LONDON
    next_run_date: SAT 30-OCT-2010 03:00:00 BST +01 EUROPE/LONDON
    next_run_date: SAT 30-OCT-2010 04:00:00 BST +01 EUROPE/LONDON
    next_run_date: SAT 30-OCT-2010 23:00:00 BST +01 EUROPE/LONDON
    next_run_date: SUN 31-OCT-2010 00:00:00 BST +01 EUROPE/LONDON
    next_run_date: SUN 31-OCT-2010 01:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SUN 31-OCT-2010 02:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SUN 31-OCT-2010 03:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SUN 31-OCT-2010 04:00:00 GMT +00 EUROPE/LONDON
    next_run_date: SUN 31-OCT-2010 23:00:00 GMT +00 EUROPE/LONDON
    next_run_date: MON 01-NOV-2010 00:00:00 GMT +00 EUROPE/LONDON
    next_run_date: MON 01-NOV-2010 01:00:00 GMT +00 EUROPE/LONDON
    next_run_date: MON 01-NOV-2010 02:00:00 GMT +00 EUROPE/LONDON
    next_run_date: MON 01-NOV-2010 03:00:00 GMT +00 EUROPE/LONDON
    next_run_date: MON 01-NOV-2010 04:00:00 GMT +00 EUROPE/LONDON
    next_run_date: MON 01-NOV-2010 23:00:00 GMT +00 EUROPE/LONDON
    next_run_date: TUE 02-NOV-2010 00:00:00 GMT +00 EUROPE/LONDON
    next_run_date: TUE 02-NOV-2010 01:00:00 GMT +00 EUROPE/LONDON
    next_run_date: TUE 02-NOV-2010 02:00:00 GMT +00 EUROPE/LONDON
    next_run_date: TUE 02-NOV-2010 03:00:00 GMT +00 EUROPE/LONDON
    next_run_date: TUE 02-NOV-2010 04:00:00 GMT +00 EUROPE/LONDON
    I created a little function to return the start date I want. The IN parameter is defaulted to NULL which will default to today:
    CREATE OR REPLACE FUNCTION get_start_date_with_timezone(p_start IN VARCHAR2 DEFAULT NULL)
    RETURN timestamp with time zone
    IS
    w_check timestamp;
    w_return timestamp with time zone;
    BEGIN
    IF p_start IS NOT NULL
    THEN
    --check if p_start is a valid date
    w_check := to_date(p_start, 'dd-mon-yyyy');
    --if you get here it is a valid date
    w_return := to_timestamp_tz(p_start||' 00:00:00 Europe/London' ,'DD-MON-YYYY HH24:MI:SS TZR');
    ELSE
    --set to midnight this morning
    w_return := to_timestamp_tz(to_char(TRUNC(systimestamp), 'dd-mon-yyyy hh24:mi:ss')||'Europe/London' ,'DD-MON-YYYY HH24:MI:SS TZR');
    END IF;
    RETURN(w_return);
    EXCEPTION
    WHEN OTHERS
    THEN
    RAISE;
    END;
    I'll use this function in a cursor for loop through dba_scheduler_schedules for the users I want using the dbms_scheduler.set_attribute.
    Thanks once again.

  • British Summer TIme problem

    I've linked iCal with MobileMe. However, if I enter a recurring weekly 10am appointment starting in February, after the end of March it displays it in Monthly view as 11am, even though in edit view for that date it shows 10am. Anybody know the solution? Kev

    its not a BST problem its a general sumer/winter time thing
    Ive put in a lot of entries in PST as I have to do things based on that time zone, but Im on CET/CEST. Time zone support is on and so far so good, but, last night the clocks went forward, and all the appointments made on PST are shown incorrectly now in CEST (i.e. they are 1 hour late).
    iCal does not take into account time changes within a time zone. All the appointments I enter now in PST are incorrect in CEST.
    Any fixes ?

  • Time didn't change (daylight savings)

    First off, I live in the Washington State in the United States. For some ungodly reason are daylight savings is different than everywhere else in the world, go figure. Anyways, this morning at 2 everything was supposed to go forward an hour but this computer didn't. I set it in my rc.conf, shouldn't that be it?
    rc.conf
    # /etc/rc.conf - Main Configuration for Arch Linux
    # LOCALIZATION
    # LOCALE: available languages can be listed with the 'locale -a' command
    # HARDWARECLOCK: set to "UTC" or "localtime"
    # TIMEZONE: timezones are found in /usr/share/zoneinfo
    # KEYMAP: keymaps are found in /usr/share/kbd/keymaps
    # CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
    # CONSOLEMAP: found in /usr/share/kbd/consoletrans
    # USECOLOR: use ANSI color sequences in startup messages
    LOCALE="en_US.utf8"
    HARDWARECLOCK="localtime"
    TIMEZONE="US/Pacific"
    KEYMAP="us"
    CONSOLEFONT=
    CONSOLEMAP=
    USECOLOR="yes"
    # HARDWARE
    # Scan hardware and load required modules at bootup
    MOD_AUTOLOAD="yes"
    # Module Blacklist - modules in this list will never be loaded by udev
    MOD_BLACKLIST=()
    # Modules to load at boot-up (in this order)
    # - prefix a module with a ! to blacklist it
    MODULES=(iwl3945 !ipw3945 acpi-cpufreq !cpufreq_ondemand cpufreq_powersave sky2 snd-mixer-oss snd-pcm-oss snd-hwdep snd-page-alloc snd-pcm snd-timer snd snd-hda-intel soundcore !sony_pi sony_laptop !sony_acpi)
    # Scan for LVM volume groups at startup, required if you use LVM
    USELVM="no"
    # NETWORKING
    HOSTNAME="reasons"
    # Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available
    # interfaces.
    # Interfaces to start at boot-up (in this order)
    # Declare each interface then list in INTERFACES
    # - prefix an entry in INTERFACES with a ! to disable it
    # - no hyphens in your interface names - Bash doesn't like it
    # Note: to use DHCP, set your interface to be "dhcp" (eth0="dhcp")
    lo="lo 127.0.0.1"
    eth0="dhcp"
    wlan0="dhcp"
    #eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
    INTERFACES=(lo !eth0 !wlan0)
    # Routes to start at boot-up (in this order)
    # Declare each route then list in ROUTES
    # - prefix an entry in ROUTES with a ! to disable it
    gateway="default gw 192.168.0.1"
    ROUTES=(!gateway)
    # Enable these network profiles at boot-up. These are only useful
    # if you happen to need multiple network configurations (ie, laptop users)
    # - set to 'menu' to present a menu during boot-up (dialog package required)
    # - prefix an entry with a ! to disable it
    # Network profiles are found in /etc/network-profiles
    #NET_PROFILES=(main)
    # DAEMONS
    # Daemons to start at boot-up (in this order)
    # - prefix a daemon with a ! to disable it
    # - prefix a daemon with a @ to start it up in the background
    DAEMONS=(@syslog-ng @netfs @acpid @crond dbus @wicd @hal @alsa @fam @mpd gdm)
    #SPLASH="fbsplash"
    # End of file

    tesjo wrote:
    The issue seems to be with the tzdata updates and locale.gen. You should have an out put of zdump something like this
    $ zdump -v US/Mountain | grep 2008
    US/Mountain Sun Mar 9 08:59:59 2008 UTC = Sun Mar 9 01:59:59 2008 MST isdst=0
    US/Mountain Sun Mar 9 09:00:00 2008 UTC = Sun Mar 9 03:00:00 2008 MDT isdst=1
    US/Mountain Sun Nov 2 07:59:59 2008 UTC = Sun Nov 2 01:59:59 2008 MDT isdst=1
    US/Mountain Sun Nov 2 08:00:00 2008 UTC = Sun Nov 2 01:00:00 2008 MST isdst=0
    If you don't have the different on/offs for dst. Run locale-gen and check again. If still no check for  /etc/locale.gen.pacnew
    Now since it is past Mar 9, you may have to set time manually using the date command or something else, but come Nov it should switch off.
    My zdump command shows in the exact same format as you, with the same times and stuff (well not the same times, but the time difference between the 1st and 2nd, 2nd and 3rd, etc). My date command and hwclock both show an hour back.  How should I fix it using the date command? Is there like a force time check thing other than rebooting? rebooting isn't working.

  • Time didn't change to daylight savings on my computer

    My computer didn't automatically change to daylight savings as in previous years; never received any software update either - I am checked off for Apple network under Preferences. My computer has OSX 10.2 - is that the problem? Thanks, Tyner

    Hi Tyner;
    Is there are reason why you have not upgrade to new versions of OS X?
    Allan

  • Dreamweaver, summer time, and synchronisation

    One of the minor but irritating and recurrent problems with
    Dreamweaver's synchronise function is that, after a change to/from
    British Summer Time (Daylight Saving Time for those of you across
    the Pond), any synchronise operation will inform you that the file
    on the server has changed since the last synchronisation and ask
    you what you want to do, even when the file is plainly the same.
    You can tell that it's a BST problem because the timestamp differs
    by exactly one hour. I'm guessing that the synch info is stored in
    the _notes/dwsync.xml in each directory. So my Q is: how can I
    reset all synch info for a site? Searching for "synch" in the fine
    help file returns nothing useful.
    This isn't something I want to spend any time on as it's
    relatively trivial, but it is annoying and renders the synch
    feature semi-useless until I manually synch all files in a site,
    and can also lead to wrong up/downloads with the danger of
    overwriting later versions. I'm using DW CS3 (aka v9) under Windows
    eXtra Pathetic. TIA for any tips.
    Cheers
    Fred

    I'm having the same problem and its about time Adobe sorted it. Still trying to work out if its a Mac client with windows server problem. Is there a way to notify Adobe without spending my life on the phone? Using CS5.5 and FTP over TLS/SSL Explicit connection

  • NX-OS - clock summer-time - Last sunday for BST?

    Hiya,
    This may be a dumb question - I may just be missing something obvious - but I'm trying to setup some NX-OS based devices (5548Ps/5020s/1000Vs) with the correct daylight savings setting for the UK - ie. british summer time.
    The definition of BST is:
    "British Summer Time (BST) starts on the last Sunday in March and ends on the last Sunday in October, at 1.00 am Greenwich Mean Time (GMT)"
    ie. it's always the 'last' sunday'. On our IOS devices we do this:
         clock timezone GMT 0
         clock summer-time BST recurring last Sun Mar 1:00 last Sun Oct 1:00
    ....but there's no equivalent 'last' keyword on NX-OS:
    clock summer-time zone-name start-week start-day start-month start-time end-week end-day end-month end-time offset-minutes
    Sometimes the 'last' sunday is the 4th, and sometimes it's the 5th...?
    Anyone know how to set it to the last sunday? Or do I just have to accept it's sometimes going to be a week out?
    Thanks,
    Rob...

    Looks like you're right Jerry! Thanks!
    Just managed to find a switch to test it on - and it works as expected:
    switch-n5k(config)# sh run | inc clock
    clock timezone GMT 0 0
    clock summer-time BST 5 Sunday March 01:00 5 Sun Oct 01:00 60
    switch-n5k(config)# sh clock
    00:56:38.908 GMT Sun Mar 27 2011
    switch-n5k(config)# sh clock
    02:02:59.779 BST Sun Mar 27 2011
    switch-5k(config)#
    Thanks,
    Rob...

  • How to detect Summer Time change (GMT or GMT+1)

    Hi all,
    My problem is that I retrieve from xml a timestamp. It indicates the London local hour.
    I do format the Calendar constructed object with SimpleDateFormat, but I have to append "GMT" or "GMT+1" (BST) to the output String.
    How do I detect when the time is BST (British Summer Time) and when Greenwich Mean Time?
    Thanks for your help.
    Best regards,
    Antonio

    Hello Jarrod
    Thank you for your help, I looked the previous threads and download .NET Framework 2.0. Finally I am able to get it work.
    Amit

  • Oracle RAC summer time

    Hi!
    Environment: Oracle RAC 9.2.0.7 in AIX 5.3.
    I have a database with the following configuration:
    $ srvctl getenv database -d mydb
    TZ=NFT-1DFT
    Because of in Spain we have summer time, I need change it. (TZ=NFT-1DFT is only valid for winter).
    I have tried:
    $ srvctl setenv database -d mydb -t TZ="NFT-1DFT,M3.5.0,M10.5.0"
    But it does not work:
    ava.lang.StringIndexOutOfBoundsException: String index out of range: -1
    at java.lang.String.substring(String.java)
    at oracle.ops.opsctl.SetenvAction.parseNameValues(SetenvAction.java:204)
    at oracle.ops.opsctl.SetenvAction.executeDatabase(SetenvAction.java:80)
    at oracle.ops.opsctl.Action.execute(Action.java:92)
    at oracle.ops.opsctl.OPSCTLDriver.execute(OPSCTLDriver.java:223)
    at oracle.ops.opsctl.OPSCTLDriver.main(OPSCTLDriver.java:121)
    ¿Could anybody help me?
    Thanks in advance.

    Unless you are on R12.1, you can't control this value. If you are on 12.1, Default Timecard Period has been added to preference Self Service Timecard Period for a Worker, where the following options are available:
    Period on or after system date
    Earliest Period prior to system date
    Closest Period prior to system date
    --Shiv                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Problem with summer time

    It seems that Nokia Communication Centre has a problem with summer time.
    This is the behaviour:
    - the problem
    . both on the phone and on the pc, time zone is CET+1 and summer time is active
    . on the phone I have a message received at 10
    . in the Communication Centre the time of the message is 11
    - test 1
    . on the phone, time zone is CET+1 and summer time is active
    . on the pc, time zone is CET+2 and summer time is NOT active
    . on the phone I have a message received at 10
    . in the Communication Centre the time of the message is 10
    - test 2
    . on the phone, time zone is CET+1 and summer time is active
    . on the pc, time zone is CET+1 and summer time is NOT active
    . on the phone I have a message received at 10
    . in the Communication Centre the time of the message is 9
    I'm using:
    . Windows XP Pro, italian, SP2
    . PC Suite 7.0.7.0, italian
    . Nokia 7310 Supernova, italian language, V 08.20

    george_12358 wrote:
    > What can I do to fix it?
    http://www.adobe.com/go/d2ab4470

  • Odd clock drift since summer time clock change

    This is a weird one. Since the clocks changed back for daylight savings time (here in the UK, on Sunday morning from BST to GMT) I've been getting a strange error: while I'm editing a file in vi(1), occasionally when I come to save it tells me the file has changed on disk (it hasn't).
    I thought I was going mad until a colleague said he's seen the same warnings on his machine in Eclipse. It seems to me like the clock is constantly drifting/being adjusted - I'm syncing with NTP to time.euro.apple.com, and I am seeing a lot of NTP updates in the logs:
    system.log:Nov 2 19:18:26 mightymac ntpd[34353]: time reset +0.280424 s
    system.log:Nov 2 20:26:10 mightymac ntpd[34353]: time reset -0.857206 s
    system.log:Nov 2 20:26:10 mightymac ntpd[34353]: frequency error -589 PPM exceeds tolerance 500 PPM
    system.log:Nov 2 21:01:15 mightymac ntpd[34353]: time reset +0.974976 s
    system.log:Nov 2 23:00:28 mightymac ntpd[34353]: time reset +0.557037 s
    system.log:Nov 2 23:34:56 mightymac ntpd[34353]: time reset +0.960510 s
    system.log:Nov 3 09:49:37 mightymac ntpd[34353]: time reset -1.004375 s
    system.log:Nov 3 10:07:17 mightymac ntpd[34353]: time reset +0.491741 s
    These are big jumps - a second, half a second, much more than I'd expect to see. Given it's happening on a colleagues machine we can rule out my clock battery or other local hardware/software issues, it's happening both when I'm at work and at home (on two different networks), and it's only happening since the summer time change on Sunday.
    Has anyone else seen this? This is on 10.6.4, on two machines that have not been rebooted since the clocks changed.

    I have a similar problem - when I start up my clock has advanced about 13 hours. It seems to have been doing this since daylight savings changed. It has the right time zone and I have unlinked synchronisation but it keeps happening even when it is locked.

  • Change to summer time (windows)

    Hi experts,
    We will change to summer time this weekend, and the windows will change this automatically in the server, but we have in SAP system the time zone UTC-3, with summer time could be UTC-2.
    The question is: I need to change the both time? If i only change the time of Windows, is there any bad effects in SAP system?
    Somebody know any sapnote about it?
    Thanks!
    Best Regards,
    Gabriel

    Hello Gabriel
    Automatic time change on Windows servers should be enough.
    Please have a look at OSS notes 161837, 398374 and the related notes mentioned.

  • Summer Time -- Winter Time

    Hello fellow admins,
    In Europe, during the night of october 29th to october 30th, we will change from Summer time to Winter Time.
    In my company we have always stopped our SAP systems during the "time leap" from 3am to 2am.
    We know that, when setting the system parameter zdate/DSTswitch_contloctime = on, the SAP abap kernel will be able to "slow" time to avoid the time leap.
    We are now investigating if we could avoid to stop our ECC6, R/3 4.7, SRM and CRM systems.
    What bothers us is that SAP only guarantees the BASIS module and tell that we should check each functional module to decide if a time difference between SAP time and legal time up to 30 minutes is acceptable for our business processes.
    I would like to do a kind of poll to know what you do with your own SAP systems.
    Could you, please, answer by telling which SAP system is used and if you stop it or keep it running during the time change ?
    Thank you in advance for sharing information.
    Regards,
    Olivier

    Hello
    During that period our business will send a notice to the end users that the system will not available during this period and we stop all our applications(DEV, QAS & PRD) ECC, ECC HCM, EP, SRM, Solman.
    It's always good to bring down the system to avoid any business impact or any new challenges.
    Thanks & regards
    bala

Maybe you are looking for

  • Projects Will Not Open

    Ok, I will start this sad story from the beginning. When I returned home from Xmas holiday I found my hard drive crashing. I took my Mac and all my software disk to a guy that has always done me right and he began to salvage what he could off the fai

  • Exception while perfroming Java mapping in XI

    Hi there, Im doing some java mapping in XI using the standard/classic DOM and JAXP packages, I have tested everything outside XI and the code seems to be OK. However when I deploy the code into XI self and run a test, something goes wrong. This is th

  • User Device Affinity PXE Setting

    In the settings for PXE on a DP, there is an option for user device affinity with three possible choices.  Do not use UDA, use UDA with manual approval or use UDA with automatic approval.  What exactly do these settings do?  The TechNet info is a bit

  • Parameter lookandfeel in formsweb.cfg

    Hi! Possible values for parameter lookandfeel is *"Generic"* or *"Oracle"* in formsweb.cfg, is it possible to modify lookandfeel=Oracle more than colorscheme or is it possible to develop our own lookandfeel? Has anyone any nice GUI examples for Forms

  • JTA transaction unexpectedly rolled back

    I have a Spring Java web app deployed on OC4J 10.1.3.3 using Toplink as the container managed persistence. When my app is launched a named query is executed that uses JPQL to load up collections of objects. It is failing with the subject line excepti