GDateTime

Some readers may remember that I spent some time working on a DateTime structure for GLib last year. After much refinement by others better than myself, it has been included in GLib master. Much thanks to Thiago Sousa Santos, Emmanuele Bassi, and the countless reviewers.

You can find some quick examples here.

GDateTime is both immutable and reference counted. See gdatetime.h for relevant API.

  1. {
  2.   GDateTime *dt;
  3.   char *str;
  4.  
  5.   dt = g_date_time_new_now();
  6.   str = g_date_time_format(dt, "It is currently %x %X %z");
  7.   g_print("%s\n", str);
  8.  
  9.   g_date_time_unref(dt);
  10.   g_free(str);
  11. }
Comments closed | Trackbacks closed

Comments (14)

  1. frederik wrote:

    This was about time! Thank you.

    Wednesday, August 25, 2010 at 6:43 pm #
  2. Chenthill wrote:

    Does it have the timezone convertion functions ?

    Can one start replacing time_t with GDateTime ?

    Thursday, August 26, 2010 at 1:12 am #
  3. chergert wrote:

    You could probably start replacing time_t code with it.

    As for timezone conversion, what type of conversions do you want to do? Simply translating between localtime and utc is trivial with the api using g_date_time_to_utc().

    Thursday, August 26, 2010 at 1:15 am #
  4. Emmanuel wrote:

    I don’t think g_date_time_printf is a good name for this function. Usually such functions are named foo_to_string (like g_icon_to_string, g_inet_address_to_string, …)

    It would be nice to keep GDateTime API consistant with what already exists.

    Thursday, August 26, 2010 at 2:15 am #
  5. chergert wrote:

    The to_string() methods don’t take parameters for formatting. So it wouldn’t be any more consistent.

    Thursday, August 26, 2010 at 2:34 am #
  6. frederik wrote:

    @Emmanuel: Yes, “_printf” usually prints something (formatted). However, “_to_string” functions usually don’t take a format string parameter. I would call it “_format”.

    Thursday, August 26, 2010 at 2:39 am #
  7. Philip Van Hoof wrote:

    @Emmanuel:

    I agree that to_string() is nicer and probably fits better with Vala. However, for format strings it looks like GLib usually uses _printf style:

    g_string_printf
    g_string_append_printf
    g_strdup_printf
    g_markup_printf_escaped

    vs.

    g_quark_to_string
    g_credentials_to_string
    g_icon_to_string
    g_inet_address_to_string

    Thursday, August 26, 2010 at 2:39 am #
  8. frederik wrote:

    @Philip Van Hoof: But they are only called “_printf” if they take printf format specifiers plus varargs. The date formatting has different format specifiers and takes no varargs.

    Thursday, August 26, 2010 at 2:51 am #
  9. Daniel Morgan wrote:

    Very nice. I like the sorting of gdatetime. Does it include your changes for gcalendar as well?

    Thursday, August 26, 2010 at 4:40 am #
  10. hb wrote:

    Great, thanks for that work. Are there plans to include ISO 8601 string parsing, too?

    Thursday, August 26, 2010 at 8:12 am #
  11. Miguel de Icaza wrote:

    The only odd thing here is that this is reference counted.

    The value of reference counting here in my opinion is very low. It should instead have structure semantics.

    Similar to “struct stat” in the kernel API.

    Thursday, August 26, 2010 at 8:28 am #
  12. chergert wrote:

    Miguel, I actually agree. In fact, that is how I originally wrote it. However, it was decided that having more structures on the stack will end up being tougher to maintain and build an API around.

    Thursday, August 26, 2010 at 9:38 am #
  13. chergert wrote:

    Daniel, GCalendar stuff is not yet added. But the goal is to do that later on once we can solidify the API.

    hb, it should be trivial to add 8601 parsing since you can convert to/from GTimeVal.

    Thursday, August 26, 2010 at 9:41 am #
  14. Morten Welinder wrote:

    The implementation is an unmitigated disaster. See bug 628137.

    This should clearly have been using GDate for all the date calculations. It is non-trivial to get right.

    Even worse, there seems to have been no thoughts about error handling in the API. That really should be fixed before it gets into a stable release.

    Friday, August 27, 2010 at 11:03 am #