clock is wrong

[ikarus]

The time as shown by the on-screen clock is always one hour fast. When I go to clock settings and enter my root password I can change the system to manual and correct the reading but after a couple of seconds it changes back to being an hour fast.

Even when I resort to CLI and use ntpdate it shows up as an hour fast. I think the time zone information may be wrong but I don't know how to access this.

My timezone is INDIAN/MAURITIUS which was using daylight saving time last year but not currently.

Ikarus

[bubbel]

Hello ikarus,

you must do the following:

Right-click on the clock > Date and Time Setting  >Date and time set automatically.

Greetings
bubbel

[ikarus]

Hello bubbel

Thanks for your reply.

I have the system set to automatic as you suggest. The clock is still one hour fast. I think the time-zone data for Mauritius is wrong in Pardus. We do not have DST here this year.

Why will the system not let me set the time manually? I do not want to do this but it would be ok for a quick work-around.

Best regards

ikarus

[Michiel]

Quite confusing, as far as I get it from:

http://blogs.technet.com/dst2007/archive/2008/10/02/guidance-for-mauritius-on-upcoming-daylight-saving-time-implementation-for-2008-2009.aspx

and

http://www.noulakaz.net/weblog/2008/10/17/effect-of-mauritian-summer-time-on-linux-systems/

Mauritius DID have DST from 2008-2009 and now you say it doesn't, anyway....perhaps one of the above links could help you (I have not checked whether there is an exdate package in Pardus).

The strange thing for me is why this should all be so complex and why the NTP time servers do not simply add a specific date format for Mauritius so that they always broadcast the correct time and end-users do not have to bother adjusting it with all sorts of workarounds...

[Michiel]

As far as I can see in the installed packages, Pardus seems to use rdate, version 1.4 to retrieve current time and date

However the actual problem might reside in the pisi package pytz
Pardus currently uses version 2009g whilst as of September 29th the current version is 2009n ( http://pypi.python.org/pypi/pytz )

I suggest you write a bug report for the Pardus developers to dive in this sometimes a bit complex stuff.

In the end it depends on implementing an up-to-date timezone database, because in the timezone-databases all current decision on DST and so on should be stored.

[ikarus]

hi Michiel

Thanks for your response - I shall have a look at the rdate packeage.

Regarding DST in Mauritius - this was a one year trial and was discontinued from this year. Ubuntu's tzdata appears to have it correct.

NTP time servers, as I understand it, do not broadcast local time to anywhere. I believe the data they send is in fact "UNIX EPOCH" time which is referenced to a time/date which commenced in 1970 or thereabouts. So it is purely a number which increments and is the same anywhere in the world at any particular moment in time.  The time-clock software running in the OS converts this number to a recognisable format  taking into account the user's (stated) location.

Having said that, my latest simple work-around is to change my local time zone to "Dubai" . They've got my time over there 

Best regards

ikarus

PS I believe that the UNIX EPOCH system actually runs out some time around two thousand and thirty something, due to the counter reaching overflow. I don't know what they plan to do about this but I expect I'll be long gone before then !!! 

[johnh3]

Its a old  bug report written about automatic time settings by myself. Maybe you could provide with more info there:
http://bugs.pardus.org.tr/show_bug.cgi?id=10719

[Michiel]

The bug you mentioned, to be honest for me was not very clear what you meant there.

 For the current issue I posted a bug report for you:

http://bugs.pardus.org.tr/show_bug.cgi?id=11462

[ikarus]

to johnh3 :

Yes, many thanks for that and I agree there is something wrong about the way we cannot control the clock settings either as user or root.

However, I think maybe the timezone-data is yet another separate issue to follow up

*********************************************************************************************************

to Michiel :

I completely agree with your final comment.

I went ahead with installing the pytz software and it installed correctly. I thought that maybe the OS would pick up on this and use the new data automatically. However its no go - the time remains an hour fast for poor little Mauritius!

So, now I'm not sure if its the 2009n data that's wrong  or whether pytz itself is mis-managing it. It all looks awafully complicated and well beyond my comprehension!   

I guess, as you say, a bug report is in order here. Now I'll try to work out how to do that.   


ikarus

[ikarus]

Michiel:

Thanks for filing that bug-report. You saved my brain 

ikarus

[johnh3]

I mean when you want to put automatic time and date settings permanent it not works. If you go in in the meny or on the clock on the list below and do the necessary settings and restart the PC and check there again its disconnected.

Atleast it was like that when I wrote the bug report:
http://bugs.pardus.org.tr/show_bug.cgi?id=10719

Maybe someone can check if it is like that now to? I dont know if its fixed with updates later.
I write this from a Windows PC and can not see myself at the moment.

[Michiel]

The story widens...:


http://bugs.pardus.org.tr/show_bug.cgi?id=11462


Serdar Dalgıç <dalgic.srdr@gmail.com> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
                CC|                            |gokcen@pardus.org.tr,
                  |                            |ozan@pardus.org.tr
         Component|pytz                        |kdebase
        AssignedTo|dalgic.srdr@gmail.com       |gokcen@pardus.org.tr



--- Comment #2 from Serdar Dalgıç <dalgic.srdr@gmail.com>  2009-10-28 13:57:52 ---
(Cevaplanan yorum: #1)
> (In reply to comment #0)
>
>
> Additional info by that user
>
> "I went ahead with installing the pytz software and it installed correctly. I
> thought that maybe the OS would pick up on this and use the new data
> automatically. However its no go - the time remains an hour fast for poor
> little Mauritius!"

It's an interesting situation imho

The user is using KDE as a desktop environment I guess. Problem is not related
with pytz package, it is not used in base programs of Pardus.

The problem may be related to kdebase or workspace packages etc. But no clue on
my side.

I'm adding Ozan and Gokcen to the bug report, maybe they may have a thought on
this issue or so. I'm also assigning the bug to kdebase package, if the problem
is not related to it, Gokcen would change the component.

[Michiel]

http://bugs.pardus.org.tr/show_bug.cgi?id=11462


Fatih Aşıcı <fatih@pardus.org.tr> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
         Component|kdebase                     |glibc-zoneinfo
        AssignedTo|gokcen@pardus.org.tr        |onur@pardus.org.tr




--- Comment #3 from Fatih Aşıcı <fatih@pardus.org.tr>  2009-10-28 23:04:53 ---
glibc-zoneinfo must be fixed. We should consider using tzdata archives here
[1].

[1] http://ftp://elsie.nci.nih.gov/pub/

[scutiform]

I also had a problem with the clock time being one hour out.  I am in England, so we are on GMT, however, last week we were on BST and I just could not get the clock to stay.  It sorted it self out only when we moved to GMT.

[Michiel]

--- Comment #8 from Onur Küçük <onur@pardus.org.tr>  2009-12-26 20:18:49 ---
The bug is fixed in testing repository and 2009.1 repository. Since the changes
are in system.base it is difficult and risky to do the changes by hand, so I
suggest either wait for the 2009.1 marked as stable and merged to 2009 (on jan
15) or "remove 2009 repository and add 2009.1 repository and do an update".