Bug 68312 - Date selection calendar widget starts on Sunday when using sv_SE
Date selection calendar widget starts on Sunday when using sv_SE
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: firstboot (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
:
Depends On:
Blocks: 67217
  Show dependency treegraph
 
Reported: 2002-07-08 21:30 EDT by Christian Rose
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-11 15:25:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christian Rose 2002-07-08 21:30:53 EDT
Tested with Limbo and sv_SE as locale.

The firstboot date configuration calendar widget displays Sunday as the first
day of the week. Sweden has used ISO 8601 and Monday as first day of week for
decades. You simply cannot buy any Swedish calendars or time planners with
anything but Monday as the first day of week, and Monday as first day of week is
what people use and expect.
The date selection calendar widget displaying Sunday as first day of week when
using sv_SE locale is hence a bug (and an eye-catching one too).
Comment 1 Brent Fox 2002-07-11 12:42:10 EDT
dateconfig just calls the gtk Calendar widget, which has some interesting
behavior.  In my opinion, gtk should be locale aware so that it detects if the
specified locale needs to have the week start on monday.  I don't think that
dateconfig should have to pass any special options to the calendar for this to work.

As an aside, I tried to change the day ordering on the calendar with:
self.cal.display_options(gtk.CALENDAR_SHOW_DAY_NAMES)

This will make the week start with Monday, but it also hides the names for the
days of the week and it also hides the widgets that let you change the month and
year.  I imagine that this same problem occurs with the clock on the gnome panel.

Changing component to gtk2.
Comment 2 Owen Taylor 2002-07-11 15:06:27 EDT
 "As an aside, I tried to change the day ordering on the calendar with:
  self.cal.display_options(gtk.CALENDAR_SHOW_DAY_NAMES)"

Sounds like a PyGtk bug; the options are:

  GTK_CALENDAR_SHOW_HEADING		= 1 << 0,
  GTK_CALENDAR_SHOW_DAY_NAMES		= 1 << 1,
  GTK_CALENDAR_NO_MONTH_CHANGE		= 1 << 2,
  GTK_CALENDAR_SHOW_WEEK_NUMBERS	= 1 << 3,
  GTK_CALENDAR_WEEK_START_MONDAY	= 1 << 4

WEEK_START_MONDAY is independent of SHOW_DAY_NAMES.

There is basically no chance at all I'm going to change this
for GTK+; for one thing, changing the default
to be locale sensitive for the  "GTK_CALENDAR_WEEK_START_MONDAY" option 
is an API change.

Plus, this information is not encoded in the locale, so GTK+
would have to keep around a table of some sort, and I don't
know what that table woul look like.

Assigning back to firstboot since I don't plan on fixing it within
GTK+.

Comment 3 Christian Rose 2002-07-11 15:25:25 EDT
> There is basically no chance at all I'm going to change this
> for GTK+; for one thing, changing the default
> to be locale sensitive for the  "GTK_CALENDAR_WEEK_START_MONDAY" option 
> is an API change.

I figured so. I'd like this for the next API-changing gtk+ however. I'll file an
upstream bug report.


> Plus, this information is not encoded in the locale, so GTK+
> would have to keep around a table of some sort, and I don't
> know what that table woul look like.

Well, that's an implementation detail. The correct fix would be for this to be
in locale data but the reality is that locale data is lacking -- another example
that comes to mind is thousands seperators -- and changes in locale definitions
take years before they become reality. Also, other environments like Windows and
the Mac have been able to handle this properly for at least a decade, and it
seems rather silly that this environment can't.
I see no other solution than for gtk+ to accomodate for this until this
information is available in the locales themselves some day (ever?).
Comment 4 Brent Fox 2002-07-11 15:31:54 EDT
If I fix it in dateconfig, I'd have to maintain a table of the locales too, and
that sounds even worse than doing it inside GTK.  Not only that, but every app
that ever uses GTK Calendar would have to implement it all over again.  

I really feel like this should be done in GTK but if that won't happen, the only
thing I can do is mark this as 'wontfix'.  I hate to do that, but I don't know
what else to do.  :(
Comment 5 Christian Rose 2002-07-11 20:16:14 EDT
Reported upstream for gtk+ as http://bugzilla.gnome.org/show_bug.cgi?id=87977.

Note You need to log in before you can comment on or make changes to this bug.