all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Deniz Dogan <deniz.a.m.dogan@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Time string format
Date: Sat, 20 Nov 2010 12:09:26 +0200	[thread overview]
Message-ID: <83aal4b92h.fsf@gnu.org> (raw)
In-Reply-To: <AANLkTimsHj=OTU6ANLWNJCZHtasxiyLqgBstMcJQAK3v@mail.gmail.com>

> From: Deniz Dogan <deniz.a.m.dogan@gmail.com>
> Date: Sat, 20 Nov 2010 03:49:24 +0100
> Cc: emacs-devel@gnu.org
> 
> 2010/11/19 Eli Zaretskii <eliz@gnu.org>:
> > time.el:display-time-string-forms believes that the right format for
> > displaying the date in the mode-line tooltip is "%a %b %e, %Y".  This
> > is not necessarily TRT in languages other than English, because
> > putting the month name before the day of the month does not
> > necessarily read well in other languages.
> >
> > Would it be a good idea to have an element of language-info-alist that
> > provides a proper format for this?
> >
> >
> 
> In the docstring for `format-time-string':

Granted, I've read that ;-)

> %c is the locale's date and time format.
> %x is the locale's "preferred" date format.
> %X is the locale's "preferred" time format.
> %EX is a locale's alternative version of %X;
> %OX is like %X, but uses the locale's number symbols.
> 
> One of these or a combination of multiple formats seems ideal to me.

I think you are missing the point.  The issue is not what each of the
format specifiers produce, the issue is their order in a
_well-formatted_and_short_date_ string.  When viewed from this POV, I
think you will agree with me that

  . %x is inappropriate, because in most (if not all) locales it
    returns a numerical date, like 11/22/33, while time.el wants to
    produce human-readable names of the month and the week-day

  . %X, %EX, and %OX are irrelevant, because I was talking about
    the date, not the time

  . %c is inappropriate, because it shows the time together with the
    date

  . any combination of the above will be inappropriate for the same
    reasons the individual specifiers are

It is therefore a small wonder that time.el does not use any of these,
but instead attempts to define its own format.  The problem is that
the result is not correct for some locales/languages.  I was asking
about a good way of having that fixed.




  reply	other threads:[~2010-11-20 10:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-19 18:42 Time string format Eli Zaretskii
2010-11-19 18:51 ` Lennart Borgman
2010-11-19 19:03   ` Eli Zaretskii
2010-11-19 19:36     ` Lennart Borgman
2010-11-19 22:15       ` Eli Zaretskii
2010-11-20  1:25         ` Lennart Borgman
2010-11-20  9:43           ` Eli Zaretskii
2010-11-20 12:08             ` Lennart Borgman
2010-11-20 12:38               ` Eli Zaretskii
2010-11-20 13:34                 ` Lennart Borgman
2010-11-20 13:36                   ` Lennart Borgman
2010-11-20 15:39                     ` Eli Zaretskii
2010-11-20 16:17                       ` Lennart Borgman
2010-11-20 16:39                         ` Eli Zaretskii
2010-11-20 16:49                         ` Óscar Fuentes
2010-11-21 13:53                           ` Stephen J. Turnbull
2010-11-21 13:55                             ` Lennart Borgman
2010-11-21 14:25                               ` Stephen J. Turnbull
2010-11-21 16:07                                 ` Lennart Borgman
2010-11-22  4:19                                   ` Stephen J. Turnbull
2010-11-22 11:27                                     ` Lennart Borgman
2010-11-21 15:23                               ` Harald Hanche-Olsen
2010-11-20 15:30                   ` Eli Zaretskii
2010-11-20 15:39                     ` Lennart Borgman
2010-11-20 15:43                       ` Eli Zaretskii
2010-11-20  2:49 ` Deniz Dogan
2010-11-20 10:09   ` Eli Zaretskii [this message]
2010-11-20  3:47 ` David De La Harpe Golden
2010-11-20 10:28   ` Eli Zaretskii
2010-11-20 18:10     ` David De La Harpe Golden
2010-11-20 21:23       ` David De La Harpe Golden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83aal4b92h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=deniz.a.m.dogan@gmail.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.