Bug 473445

The first day of the week in en_GB locale should be Monday, not Tuesday or Sunday.

Anyway, I am experiencing the same issue, see screenshot attached.

Created attachment 325236 [details]
Date applet in action

(In reply to comment #1)
> The first day of the week in en_GB locale should be Monday, not Tuesday or
> Sunday.

at least it used to be that way in Fedora 9 and earlier versions (I mean Monday as a first day of the week, not Sunday).

*** Bug 474104 has been marked as a duplicate of this bug. ***

I have the same issue with en_GB. I checked en_US and it appears to work (although 1st day is Sunday). I tried fr_FR and again it works, first day is Monday.

So I copied the:

week    7;19971201;4
first_weekday 1
first_workday 1

From fr_FR to en_GB and there is no change. Week still starts on Tuesday. The locale file for en)GB even listed MON as the first day. So it would appear that for some reason the date applet is not reading en_GB or is reading the wrong en_GB.

*** Bug 474566 has been marked as a duplicate of this bug. ***

seems to be a libc locale data issue.

nl_langinfo (_NL_TIME_FIRST_WEEKDAY) returns 2 instead of 1 for en_GB.utf8.

reassigning...

Disappointing that this was not fixed in the 2.9-3 update... I'm not sure why this is marked Severity: Low. This is a fairly obvious and embarrassing bug with an easy fix.

http://sourceware.org/bugzilla/show_bug.cgi?id=7068

The patch in that link doesn't work for me (or I've made a mistake).

I changed :

week    7;19971201;4

to

week    7;19971130;4

in /usr/share/i18n/locales/en_GB and restarted. No change. I even removed the clock applet and re-added it.

Also, I've read the ISO standard and 7;19971201;4 is correct for en_GB. SO I think the problem might be with the clock applet. Note evolution doesn't have this problem. Can someone confirm whether this bug appears in KDE or some other non-gnome environment.

> Also, I've read the ISO standard and 7;19971201;4 is correct for en_GB.

You are correct - GB week starts on Monday. The correct values are:

week    7;19971201;4
first_weekday 1
first_workday 1

But editing /usr/share/i18n/locales/en_GB won't help - I think you would need to recompile glibc-common. The reason the bug doesn't appear in evolution is because it has its own first-weekday preference. Likewise, cal ignores first-weekday from locale.

It is almost unbelievable that after years of the en_GB locale being broken by having the week starting on Sunday, it has now been "fixed" incorrectly!

I can confirm that rebuilding glibc-common works.

yumdownloader --source glibc
rpm -i glibc-2.9-3.src.rpm
tar xvfj rpmbuild/SOURCES/glibc-20081113T2206.tar.bz2 
vim glibc-20081113T2206/localedata/locales/en_GB (edit as above)
rm glibc-20081113T2206/localedata/locales/en_GB~
tar -cjf glibc-20081113T2206.tar.bz2 glibc-20081113T2206/
mv glibc-20081113T2206.tar.bz2 rpmbuild/SOURCES/
rpmbuild -bb rpmbuild/SPECS/glibc.spec 
su -c "rpm -ivh --replacepkgs --replacefiles rpmbuild/RPMS/x86_64/glibc-common-2.9-3.x86_64.rpm"

Logout.

There's already a fedora patch of en_GB in the glibc sources - *please* add this one also instead of just waiting for upstream to correct.

(In reply to comment #11)
> I can confirm that rebuilding glibc-common works.

Me too. The instructions above work just fine (F10 x86_64 here). Would be really good to see an official patch/fix for this as it is very annoying and very apparent.

Not convinced that GB/UK weeks start on a Monday anyway, I live here and to me it is always a Sunday for new week, but that's for another discussion.

I'm from the UK, and I've always considered the UK week to start on a Monday (as it has in previous versions of Fedora). Any idea when this is going to be fixed - while it isn't a problem, it is quite annoying...

(In reply to comment #13)
> while it isn't a problem, it is quite annoying...

It *is* a problem.

Since this error was introduced I've made several (real-life) date based errors because I'm used to quickly glancing at the clock/date applet to work out dates <-> days of week.

Sure, I should probably have examined the column headings in more detail, but that's not human nature - in the time I've been using the applet I've trained myself to expect the left column to be Monday. That's the point of it - it's quick and easy to use - and it was great for this use case.

The fool-proof way of avoiding these mistakes has been to remove the applet.

Suggest reporter or owner add the EASYFIX keyword?

I'm glad someone else has voiced that opinion, because I too have found it incredibly annoying that I can't quickly and easily look across a week. I've followed the above advice and recompiled glibc, but if there is a critical flaw in glibc and a new version gets pushed I'm going to have to do it again until the patch is submitted.

I've made it known on the sourceware bug report that that patch is invalid, and can it be updated to the correct days.

I appear to be getting an issue when creating the RPM, this is the last output I got from rpmbuild -bb rpmbuild/SPECS/glibc.spec

make[2]: Entering directory `/root/rpmbuild/BUILD/glibc-20081113T2206/timezone'
make[2]: *** [/root/rpmbuild/BUILDROOT/glibc-2.9-3.x86_64/usr/share/zoneinfo/right/Asia/Riyadh89] Segmentation fault
make[2]: Leaving directory `/root/rpmbuild/BUILD/glibc-20081113T2206/timezone'
make[1]: *** [timezone/subdir_install] Error 2
make[1]: Leaving directory `/root/rpmbuild/BUILD/glibc-20081113T2206'
make: *** [install] Error 2
make: Leaving directory `/root/rpmbuild/BUILD/glibc-20081113T2206/build-x86_64-linuxnptl'
error: Bad exit status from /var/tmp/rpm-tmp.srAOUT (%install)

I am also suffering from an inability to create the new RPM with the same fault as noted in comment #17

Regards,

Steve Milner

Created attachment 333211 [details]
a patch for the change to the locale file

Created attachment 333212 [details]
a patch to update the spec file to include the previously attached new patch

now you can install the src rpm, add the new patch file to the SOURCES folder, apply /this/ patch to the spec file and then rebuild.  it will make a 2.9-4 version which can be applied with yum --nogpgcheck localinstall.

if you're on i386 with an i686 glibc you might need to rebuild twice - once including the --target i686 switch.

i've tried this on i386/i686 and it's working.  i'll try building it on x86_64 tomorrow and see if i get the problem that was reported in comment #17 and comment #18.

I have tried the patches, and get this error while performing the rpmbuild

make[2]: *** [/home/steve/rpmbuild/BUILD/glibc-20081113T2206/build-x86_64-linuxnptl/sunrpc/rpcsvc/bootparam_prot.stmp] Segmentation fault
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/steve/rpmbuild/BUILD/glibc-20081113T2206/sunrpc'
make[1]: *** [sunrpc/others] Error 2
make[1]: Leaving directory `/home/steve/rpmbuild/BUILD/glibc-20081113T2206'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.OTqEnw (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.OTqEnw (%build)

Sorry.

Steve

re comment #21: yup.  that appears to be x86_64 specific and also not related to the patch - the same thing happens if you try to rebuild glibc without the patch.  suggestions welcome :-)  (i've asked about it on fedora-devel-list.)

can someone confirm it works okay on i386?

(In reply to comment #20)
> Created an attachment (id=333212) [details]
> a patch to update the spec file to include the previously attached new patch
> 
> now you can install the src rpm, add the new patch file to the SOURCES folder,
> apply /this/ patch to the spec file and then rebuild.  it will make a 2.9-4
> version which can be applied with yum --nogpgcheck localinstall.

a lame question - how to apply the patch?

patch my.patch

does nothing :(

when I type:

patch -p1 <my.patch or patch <my.patch, I get this:

[root@m4300 SOURCES]# patch -p1 <my.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- glibc-20081113T2206/localedata/locales/en_GB-2.9-3	2009-02-24 17:26:43.000000000 +0000
|+++ glibc-20081113T2206/localedata/locales/en_GB	2009-02-24 17:28:13.000000000 +0000
--------------------------
File to patch:

(In reply to comment #23)
> (In reply to comment #20)
> > Created an attachment (id=333212) [details] [details]
> > a patch to update the spec file to include the previously attached new patch
> > 
> > now you can install the src rpm, add the new patch file to the SOURCES folder,
> > apply /this/ patch to the spec file and then rebuild.  it will make a 2.9-4
> > version which can be applied with yum --nogpgcheck localinstall.
> 
> a lame question - how to apply the patch?
> 
> patch my.patch
> 
> does nothing :(

apologies.  to apply the patch to the spec file i do this:

cd to ~/rpmbuild
download the spec file patch as glibc.spec-2.9-3-2.9-4.diff
patch -p0 < glibc.spec-2.9-3-2.9-4.diff

that should work.  :-)

Awesome!

that worked for me :) also, I've managed to rebuild glibc and installed it - after restart finally Monday is a first day of the week in date-applet :)

many thanks!

wow, that was quick!  it took me a few hours to rebuild (i386 and i686).

thanks for checking and confirming.  hopefully someone fedora-ish will be able to check in this change soon.  :-)

(In reply to comment #22)
> re comment #21: yup.  that appears to be x86_64 specific and also not related
> to the patch - the same thing happens if you try to rebuild glibc without the
> patch.  suggestions welcome :-)  (i've asked about it on fedora-devel-list.)
> 
> can someone confirm it works okay on i386?

Thank you for all your help regardless.

I'm afraid I haven't got the skills to even begin to fix that - sorry.

Regards,

Steve

(In reply to comment #22)
> re comment #21: yup.  that appears to be x86_64 specific and also not related
> to the patch - the same thing happens if you try to rebuild glibc without the
> patch.  suggestions welcome :-)  (i've asked about it on fedora-devel-list.)
> 
> can someone confirm it works okay on i386?

it seems to work ok on i386, will test it on my home machine too (also i386).
not using x86_64 yet :)

Created attachment 335339 [details]
fix LC_TIME in en_GB

updated to include corresponding fix to the 'day' and 'abday' arrays of strings so that they both start with "Mon"/"Monday".  sorry i missed this before - hadn't bothered to wade through the unicode values .. or read the man pages!

see `man 5 locale`, ISO 14652 (apparently) and http://sourceware.org/ml/libc-alpha/2008-06/msg00015.html for further details.

i haven't actually tried the new patch yet.  it might well break any apps which (apparently incorrectly) rely on the 'day' and 'abday' arrays starting with "Sunday" ... which might well be all/most apps.

please try it out with any apps you can think of which display weekdays.  please check what they say both before and after this latest patch.  cheers.

(In reply to comment #31)
> i haven't actually tried the new patch yet.  it might well break any apps which
> (apparently incorrectly) rely on the 'day' and 'abday' arrays starting with
> "Sunday" ... which might well be all/most apps.
> 
> please try it out with any apps you can think of which display weekdays. 
> please check what they say both before and after this latest patch.  cheers.  

I have applied solution mentioned above and it works fine for me. Date / weather applet is showing dates correctly now. Evolution uses its own locale settings, so it does not apply there.

This used to show Tuesday as first day of the week so I assume, anything relaying on that should work incorrectly anyway.

The one thing which is not solved yet is time - I guess UK uses 24h time (see stations, airports etc) not 12h - apparently Evolution uses locale settings for emails list and despite calendar settings it shows there 12h time rather then 24h as set in Calendar's settings.

(In reply to comment #32)
> I have applied solution mentioned above and it works fine for me. Date /
> weather applet is showing dates correctly now. Evolution uses its own locale
> settings, so it does not apply there.
> 
> This used to show Tuesday as first day of the week so I assume, anything
> relaying on that should work incorrectly anyway.
> 
> The one thing which is not solved yet is time - I guess UK uses 24h time (see
> stations, airports etc) not 12h - apparently Evolution uses locale settings for
> emails list and despite calendar settings it shows there 12h time rather then
> 24h as set in Calendar's settings.  

are you sure you're using the new patch from comment #30, instead of the patch from comment #19?  i've just tried the new one (from comment #30) and now the weeks start on the correct _date_ (this week starts on the 16th) but the text names of the days are wrong - gnome's panel clock says that the 16th was a tuesday, as does evolution.

speaking of evolution, the same is true of the calendar views and email lists in my evolution - so it looks like it's using the system locale settings now, not its own.  can you check what version of evo you're using?

i _think_ the UK default would be 12h, not 24h but i don't know for sure.  i'm also not sure that's even specified in the locale settings.  and if it is then i'm not sure whether evo should prefer system settings or panel calendar settings.

Jakub, what do you think we should do with this next?  i suspect we should go ahead with my first patch (from comment #19) - ideally pretty soon as it'd be great to have the days and dates looking right for UK users of F11!

then we (or the glibc people) can have a separate exercise to sort out the arrays of textual day names.  might need a very coordinated approach changing glibc for many locales at the same time as applying fixes to the major users of those strings.

(In reply to comment #33)
> are you sure you're using the new patch from comment #30, instead of the patch
> from comment #19?  i've just tried the new one (from comment #30) and now the
> weeks start on the correct _date_ (this week starts on the 16th) but the text
> names of the days are wrong - gnome's panel clock says that the 16th was a
> tuesday, as does evolution.

I've applied patch from comment #19 and that one works, haven't tried patch from comment #30 yet.

Date/Time Applet shows dates correctly for me (this week started on Monday, 16th), Evolution shows first day of the week correctly on Monday, 16th.

> speaking of evolution, the same is true of the calendar views and email lists
> in my evolution - so it looks like it's using the system locale settings now,
> not its own.  can you check what version of evo you're using?

I am using Evolution 2.24.5, evolution-2.24.5-1.fc10.i386, calendar shows date correctly as set in Evolution's setting (if I change first day of the week to Sunday, it correctly changes date widget to Sunday, 15th for current week).

> i _think_ the UK default would be 12h, not 24h but i don't know for sure.  i'm
> also not sure that's even specified in the locale settings.  and if it is then
> i'm not sure whether evo should prefer system settings or panel calendar
> settings.  

I am working in English company, we use 24h clock in there in our communication, at stations / airports time is shown using 24h clock, so I assume, it's default for this country :) Regardless of the default setting, I think locale should be easily amendable by users. At the moment there is no easy way to change locale. I cannot set 24h clock for my system - so Evolution is showing time using 12h clock on mail list, I can change it in calendar, but calendar's settings don't apply on mail list. Also I like date in format YYYY-MM-DD, but UK's date format is set to DD/MM/YYYY...

looks like the x86_64 problem might have been sorted out - not sure how.  myself and a colleague have both been able to rebuild on x86_64 today.

Steve, can you give it another try (after a 'yum update' on fedora 10) ?

it's still the patch from comment #19 that's best for now.

Hi Need

I've got the x86_64 version to build now without any problems.

However, and I'm sure this is just stupidity on my part...

I gave glibc.i686 (required for whole heap of dependencies)

but when I:

rpmbuild -bb --target=i686 rpmbuild/SPECS/glibc.spec

I get:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for i686-redhat-linux-gcc... gcc
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
error: Bad exit status from /var/tmp/rpm-tmp.JbFooG (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.JbFooG (%build)

I will continue to research this myself and I will post again if I find the solution.

Regards,

Steve

Sorry, I meant to write :

I _have_ glibc.i686

Regards,

Steve

Sorry, I meant to write :

I _have_ glibc.i686

The exact details of the error is found in the config.log:

configure:3298: checking for suffix of object files
configure:3324: gcc -c -march=i686 -mtune=generic -fasynchronous-unwind-tables -g -O3   conftest.c >&5
conftest.c:1: error: CPU you selected does not support x86-64 instruction set
configure:3327: $? = 1

So it seems I can not cross compile from my x86_64 environment into a i686 environment.

I guess there must be some packages I need to add to get this to work.

Regards,

Steve

Steve, are you sure you still need glibc.i686?

i used to have to keep a bunch of i?86 stuff around (for things like adobe flash) but i did:

yum remove glibc-2.9-3.i686 glibc-devel-2.9-3.i386

on thursday (which removed those two plus 469 dependencies including some x86_64 -devel packages which i'll add back in later if i need them) and the system _seems_ fine so far.

anyway, it's good to know that the x86_64 rebuild is working again anyway.  :-)

looking at bug 212520 it would appear that either a) it's just not possible to cross-compile glibc or b) it might be possible using the workarounds mentioned in that bug.

hope that helps.  :-)

Sadly I need Skype which is only available as a binary 32 bit.

Regards,

Steve

well, our next option (short of getting the actual package updated in fedora proper) is, according to some recent comments on fedora-devel-list, using 'mock' - if you can find out what that is and how it works.

alternatively, create a VM, install 32 bit fedora on it and build it there.

Upstream contains a change.

Ulrich, i _think_ changing it that way will mean that week numbering will be calculated from Sunday when it should be Monday.  So the DoW stuff might be right but week numbering will be broken.

Do you have a link to somewhere where Samuel has given his reasoning for using Sunday for week[2] or should i just email him direct?

he says "week[2] into always be 19971130, as glibc assumes this" - well, glibc's wrong then, isn't it?

i've tried building and installing just glibc-common with Samuel's patch and the gnome panel calendar appears to be okay - both DoW and WoY look correct to me.

does anyone know any other apps i can use to test the week numbering?

This is still not fixed in Fedora 11 Preview.

Select Language as 'English (United Kingdom)' on the gdm login screen and your gnome calendar has the first day of the week as Tuesday.

Please get the fix into the final release next month, it is a major annoyance for users over here in the UK.

looks like f11 preview has glibc-2.9.90-19
do a software update and you'll pick up glibc-2.9.90-22 which, i believe, contains the fix.  from the changelog:

- update from trunk
  - further localedef fixes 

i tried it out last night and it looked okay.

I can confirm it's fixed for me with F11 preview + glibc-2.9.90-22.i686

So the problem and fix are known - but we still need an update for F10.

I can confirm this is fixed in F11 preview, with glibc-2.9.90-22 from rawhide.

Thanks.

An update for FC10 would be very appreciated. My gnome clock applet is really annoying.

Is this just going to be ignored and work continued on Fedora 10?

I have about 3000 users, and we all find that this bug is not yet resolved just plain absurd. Please up this to urgent and high priority!

Regards
Bjørge Solli
senior engineer

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

How sad that this went an entire release without being fixed. I'm not sure what the situation was with Red Hat Enterprise Linux if this was fixed or not but I would certainly have hoped so if I were paying for support.

Lee, i _think_ this is fixed, at least for fedora 11 and 12.  are you not seeing Monday as the first day of the week?

if so you might need to raise a new bug for that.  i think this one will probably be closed as soon as F10 becomes obsolete.

(In reply to comment #56)
> Lee, i _think_ this is fixed, at least for fedora 11 and 12.  are you not
> seeing Monday as the first day of the week?
> 
> if so you might need to raise a new bug for that.  i think this one will
> probably be closed as soon as F10 becomes obsolete.  

Sorry, yes it is fixed for me now in Fedora 12, didn't upgrade to 11. I'm just saying its a shame the fix was never passed back down to Fedora 10.

I need to get around to reinstalling my work PC at some point, I usually run releases for a year at least, can't keep reinstalling your work PC all the time :)

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.