Note that if you run gdmsetup that you can set "Use 24 Hour Clock" to "auto".
Does setting this value to auto (if it isn't already) make any difference?

I'm not familiar with LC_DATE and how it should affect GDM.  Perhaps you could explain how you editied the /etc/profile and /etc/environment files and explain how you expect this should affect the GDM login screen (which can also show the date).

From reading your but report, I suspect that this might be a gnome-session bug.  You seem to be complaining that logging into your session "results in a GNOME session" where the wrong date is used.  This would be a bug in gnome-session, no?

Possibly. When using LC_DATE/TIME=sv_SE.UTF-8 should present dates and time in a swedish format and language, not english dates and AM/PM time.
The session uses the values correctly when started just via xinit, so couldn't this be gdm related too?

Values in /etc/profile and environment are set manually, looking like this:

profile:
export LC_TIME="sv_SE.UTF-8"
export LC_DATE="sv_SE.UTF-8"   

environment:

LC_TIME="sv_SE.UTF-8"
LC_DATE="sv_SE.UTF-8"

This used to work before upgrading to gdm 2.20.3

When this works, are the environment variables set in your session?  So, now that things are failing, I am guessing that even though you set these variables in /etc/profile, that they aren't actually being set anymore in your user session?  Is that another way of describing the problem?

You say this stopped working when you updated to gdm 2.20.3.  What version of GDM were you using before?  It would be helpful if you could tell me what the last version of GDM that worked would be, if you have time to test the different versions between the delta of last known version that worked and 2.20.3.

Are you sure that only GDM changed?  If you upgraded all GNOME components, then the problem could also be in a different component such as gnome-session.

To be completely strict, what GDM does is run the following (note your Xsession script may be in a slightly different directory like /etc/gdm instead of /etc/X11/gdm)

/etc/X11/gdm/Xsession (command from gnome.desktop file)

in other words

/etc/X11/gdm/Xsession gnome-session

You'll note that the /etc/X11/gdm/Xsession scriopt is what sources /etc/profile.

Does it fail if you try to run it this way?

LC_DATE and _TIME are set correctly when I check them in a gnome-terminal, but I guess that reads /etc/profile every time. Problem is that they don't seem to be read in the environment gnome-session is launched.

I did the following, hoping I understood correctly:

ran xinit, launched 

 $ /etc/gdm/Xsession gnome-session

from an xterm.

This yielded a session with the proper date format, and my problematic shortcut keys also worked fine now.

How does it work if you start a GDM Failsafe session and then run the above "/etc/gdm/Xsession gnome-session" command?

Note that /etc/gdm/Xsession sources /etc/profile.  It might be useful to add some debug "echo $LC_DATE" statements in the script.  Then you should be able to check your $HOME/.xsession-errors file after you log in and see if the value is being set before launching gnome-session.

Are there any other useful errors in your $HOME/.xsession-errors file?

I'm not sure which part of GUI is discussed here, gdmlogin?, however I think one idea is to switch "%X" and "%r" for strftime() with LC_TIME instead of gettext("%H:%M:%S") then we can remove the dependencies of LC_MESSAGES.

Both gdmlogin and gdmgreeter can display a clock and, in GDM 2.20, they both use 
the same code to display clock information:

Refer to gui/gdmcommon.c in the function gdm_common_expand_text.  A label with
"%c" expands to a clock and calls gdm_common_get_clock for further expansion.

This gdm_common_get_clock function currently does the following.  Note, the
gdm_common_select_time_format returns TRUE if GDM is configured to display time
in 24-hour clock format, false for 12-hour.

        if (gdm_common_select_time_format ()) {
                str = ve_strftime (*the_tm, _("%a %b %d, %H:%M"));
        } else {
                /* Translators: You should translate time part as
                   %H:%M if your language does not have AM and PM
                   equivalent.  Note: %l is a strftime option for
                   12-hour clock format */
                str = ve_strftime (*the_tm, _("%a %b %d, %l:%M %p"));
        }

I'm not sure if this code should change to better support LC_TIME.

However, I get the feeling this bug report is actually about the time as displayed in the actual GNOME session, which is probably not a GDM bug.  But
if we can improve the way the clock is displayed in GDM, that's good too.

I think that the questionable "localization normalization" stuff introduced somewhere in gdm-2.20.x is at fault here. From /usr/local/etc/gdm/Xsession:

[zlatko@disclosure]:~$ grep -A6 "Normalize all" /usr/local/etc/gdm/Xsession
# Normalize all LC_* settings to $LANG
for var in "LC_ALL" "LC_CTYPE" "LC_NUMERIC" "LC_TIME" "LC_COLLATE" "LC_MONETARY" "LC_MESSAGES" \
	"LC_PAPER" "LC_NAME" "LC_ADDRESS" "LC_TELEPHONE" "LC_MEASUREMENT" "LC_IDENTIFICATION" ; do
  if eval "[ -n \"\$$var\" -a \"\$$var\" != \"\$LANG\" ]" ; then
    unset $var
  fi
done
[zlatko@disclosure]:~$ 

So whenever any of your $LC_* settings are different than your $LANG setting, GDM thinks that it's a good idea to "correct" that. Why? I have absolutely no idea. These are my locale settings as defined in /etc/profile and /etc/profile.d/*:

[zlatko@disclosure]:~$ locale
LANG=en_US.UTF-8
LC_CTYPE=de_AT.UTF-8
LC_NUMERIC=de_AT.UTF-8
LC_TIME=de_AT.UTF-8
LC_COLLATE=C
LC_MONETARY=de_AT.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=de_AT.UTF-8
LC_NAME=de_AT.UTF-8
LC_ADDRESS=de_AT.UTF-8
LC_TELEPHONE=de_AT.UTF-8
LC_MEASUREMENT=de_AT.UTF-8
LC_IDENTIFICATION=de_AT.UTF-8
LC_ALL=
[zlatko@disclosure]:~$ 

I want my user interface and my error messages ($LC_MESSAGES, $LANG) in English, I want all (shell script) sorting to work as expected ($LC_COLLATE), and I want all the rest to be set properly for where I live (Austria). I definitely DO NOT want everything set to $LANG - this defeats the whole point of having different $LC_* settings for different purposes (date/time, currency, numbers, etc.).

Simply commenting out the offending lines in /usr/local/etc/gdm/Xsession fixes the problem for good. From reading the comments in that file, I guess GDM's intention is to make up for broken distros that don't define locale settings properly. While this is certainly a noble purpose, I find it annoying that this "fix" actually *breaks* working setups, just because the working setup looks different than what GDM thinks it should look like. IMHO this is none of GDM's business, broken locale settings should be left up for the distros to fix.

On a similar note, I also commented out the (doubtlessly well-intended) G_BROKEN_FILENAMES/G_FILENAME_ENCODING stuff. I switched my system to UTF-8 several years ago, all my files are named properly, none of this is necessary anymore, TYVM.

Could you propose how you would like the GDM code to change by providing a patch?
We can then review the patch and get the fix upsteam if it seems reasonable.

Created attachment 109707 [details] [review]
Patch for data/Makefile.am, data/Xsession.common, data/Xsession.in, data/Xsession.solaris, data/configure.ac

I think the last report is a separated issue.
However how about the attached patch for the last report?

The idea is to separate the Xsession code.
The unset of LC_* was implemented because of some political reasons but we Sun no longer need the part.

Thanks.

Do people agree that this patch is reasonable to go into 2.20?  It looks good to me.

Yup, looks good to me too. Cool, thanks! :-)

Created attachment 109731 [details] [review]
updated patch for SVN head

I had to rework the patch a bit to get it to apply to the 2.20 branch, but I did this and this bug is now fixed in the 2.20 branch.

I found some issues with your patch which I fixed.  I am providing an updated patch for SVN head which matches the changes I made.  Jon do you think this patch should also go into SVN head.  It does seem nice to only apply the Solaris specific bits when building on Solaris, and providing a mechanism for other distros to also add their own logic to the Xsession script.  Also this patch
removes the LC_ normalizing cruft which fixes this reported bug.

Changes I made to the patch include:

- I renamed "VENDOR_XSESSION" to "DISTRO_XSESSION" since that seems a bit nicer.
- I also added Xsession.common and Xsession.solaris to EXTRA_DIST in 
  config/Makefile.am since these files need to be included with the tarball.
- I also modified the sed in config/Makefile.am to remove the @DISTRO_XSESSION@
  string and replace it with "Distro configuration section".  I do this after
  appending the DISTRO_XSESSION file to this location.  This way the a
  more readible string than "@DISTRO_XSESSION" remains in the final Xsession
  file.
- I modified config/Xsession.in to add a comment to indicate the end of the 
  section.  This way it is more clear what parts got added (if any).
- I also modified the way you were setting DISTRO_XSESSION in config/Makefile.am 
  since it seemed the way you were defining it didn't seem to work for me.

Thanks for the integration. I forgot EXTRA_DIST.
One concern is the whether we should include G_BROKEN_FILENAMES in Xsession.common by default or not.

Personally I'd like to include the value by default but I'm not sure the current stance of the other distributors. 
My understanding is, currently many distributors set G_BROKEN_FILENAMES because the GDM Xsession.in had it. If a few distributors unset G_BROKEN_FILENAMES, it's an idea to create the new Xsession.$os for the submitter and include G_BROKEN_FILENAMES in Xsession.common.

Takao, I think that it would be good to send an email to the gdm-list@gnome.org asking people their thoughts about this issue, and how they think GDM should work.  Would you mind sending such an email to the list?  Hopefully we'll get some feedback to help us know what to do.  I think most distros have a representative who is fairly active on the gdm-list.

Glad to see you figured this one out, Thomas.
Could the bug be marked as NEW/confirmed?

I'm markign this bug as closed.  I believe this bug is now fixed.  If there are any remaining issues please reopen or file a new bug.

I'm not sure why I marked this bug as closed.  It is obviously fixed in the 2.20 branch, but the patch hasn't yet gone upstream into SVN head.  See comment #14.

It just made the most sense to submit this fix upstream.  I think it is reasonable to allow this sort of mechanism for distros to easily add their own Xsession scripting.  It's common for each distro to have their own logic here.