Bug 68312

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.

 "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+.

> 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?).

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.  :(

Reported upstream for gtk+ as http://bugzilla.gnome.org/show_bug.cgi?id=87977.