indeed this would be a useful addition to glib IMHO. The returned string should be locale dependent.

By the way the api should take a GTime not a time_t for consistency with other glib api.

I'd love to have something like this for bug #324543.

What if we had:

typedef enum {
  G_TIME_COMPONENT_SHOW_DATE = 1 << 0,
  G_TIME_COMPONENT_SHOW_TIME = 1 << 1
} GTimeComponentFlags;

typedef enum {
  G_TIME_FORMAT_SHORT,
  G_TIME_FORMAT_LONG,
  G_TIME_FORMAT_CONTEXTUAL
} GTimeFormat;

char *g_format_time (GTime time, GTimeComponentFlags flags, GTimeFormat format);
char *g_format_explicit_time (int year, int month, int day,
                              int hour, int min, int sec, 
                              GTimeComponentFlags flags,
                              GTimeFormat format);

So far I can remember these cases for formatting dates and times:

  - a short string for lists and other compact displays of data
  - a long string for when you can affort the screen real estate
  - "contextual" is "Today hh:mm", "Yesterday hh:mm", "Wednesday hh:mm",
    "February 29 hh:mm", depending on the closeness to $now.

Is this just for "human-readable" date formats, or does it also cover things like 
2005-12-03 ?

GTime has been deprecated, so it should not be used in new api.

Just human-readable dates.

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

Is this in any way related to bug 21859?

> Is this in any way related to bug 21859?

Roughly. That bug is about parsing dates, and this bug is about showing (text representations of) dates.

Created attachment 101269 [details] [review]
[PATCH] Initial implementation of time formatting

this is an initial implementation of g_format_time_for_display(), similar to g_format_size_for_display(). it uses the same logic as the equivalent function inside GtkFileChooserDefault, but adds second and minute granularity; the output is a UTF-8 string that looks like:

  test format time for display:
    formatted time (now -10 seconds)     = 19 seconds ago
    formatted time (now -120 seconds)    = 19 minutes ago
    formatted time (now -3720 seconds)   = Today at 16:41
    formatted time (now -83720 seconds)  = Yesterday at 18:28
    formatted time (now -163720 seconds) = Monday
    formatted time (now -621170 seconds) = 12/10/07

improvements:
* direction-proof (dates set in the future)
* more granularity (?)
* localization

the number discrepancy is due to the "lag" introduced by testglib, in case you wonder :-)

Note that we just modified the file chooser to not say "Today at XX:XX", as "today" is rather redundant (see bug 410517). Also bear in mind that it may in some cases be desirable to explicitly request the time in a shorter format if space doesn't permit (see bug 410519).

Eek. I just want to say that I personally hate it when computers try to behave like people *talk* and display things like "yesterday at 14:13". I hate it in Evolution and the file chooser, too.

I can hardly imagine any context in a UI where seeing a point in time expressed in such a varying textual format would make sense. Especially no sense at all it makes when there are several rows of date and time in a column and the rows are sorted according to time. It makes it very hard to quickly see the relative time differences between the rows. One has to parse the individual weekday names and mentally make decisions like "was this 'Tuesday' long after the fifth of last month or not" or "hmm, the 'five minutes ago' on this row is just seconds after the '13:14' on the previous row, isn't it".

It's *much* easier when one just uses a numeric only format with leading zeros. Then everything lines up nicely, as comparing digits quickly with a glance is easy. If one also uses the ISO8601 (most significant unit first) date format, it's even easier.

You wouldn't want to scan a bank account statement, credit card bill etc if it had the amounts expressed as "two bucks", "56.37", "half your weekly salary", etc? 

And if you then say, "but the API suggested here isn't for use in tabular context, but for more prose-like contexts", well, huh? Why not then go the full way and totally try to behave like people talk and produce very free form text like "last Indepencece Day", "the upcoming New Year's Eve", "Super Bowl weekend", "the day before <spouse>'s birthday" etc. Obviousyly this would not only be language, but also country and religion dependent, and would need to be individually tweakable, with a set of personal settings  for personally important dates. I am not entirely serious here.

As far as I can see, the API is intended exactly for tabular contexts, like Evolution and the file chooser. 

What's intuitive is obviously rather subjective. :) I personally find it helpful (not necessarily being one to keep track of today's exact date), and would add that popular web applications like facebook and gmail _do_ print out dates this way, so it's not like we're doing something weird and unusual. I don't think the comparison with a credit card statement is quite right: there you already start out with a very specific context (the month of the bill).

Perhaps the best way of settling this would be to get the opinion of someone with usability experience.

Can we get something like this merged for the next release?
I'd like to use it and copy/paste sucks.

Also, I think seconds granularity is kind of ugly, if you want to display it in the file chooser, because you'll have to update it again in a second. The same probably goes for minute-granularity.

The function in the file chooser (that the patch liberally copies from) only requires updating the string once per day, which is probably fine to just ignore. People rarely keep their file chooser or Nautilus window open for more than a day.

Given the discussion surrounding size formatting elsewhere, I am very reluctant to take any more 'human-readable' formatting functions into glib at all.

*** This bug has been marked as a duplicate of bug 649900 ***