Local time seems to be what's most used by most people in a daily basis. At what time did you wake up? At eight. When is your paper due? Monday midnight.
But some of you readers may live in a connected world and usually need to schedule a developers meeting in IRC. With people from many parts of the world involved, the best way would be to use a universal time, like UTC. I usually step on problems because of Daylight Saving Times. The TV Guide is all wrong and I can't tell when they start fixing it unless I turn on the TV and check what show is on. You start reading your log files and they just jump to one hour later, or one hour earlier all over again. Using UTC would be a very good option to use on a daily basis.
The problem is nobody is used to say they have lunch at 14:00 UTC. They usually have lunch about midday, which is not 12:00 UTC at all places. Reading someone's post saying "I've had lunch too late today" which your feed reader tells you was posted at 13:00 doesn't make a lot of sense, does it?
One must account what time is used for in those situations to pick up what to use. One thing time is used is to "place" events in relation to one another, that is, which one comes before or after the other. Registering when an event happened also allows to tell what is the difference in time in relation to another event. Scheduling a future event, and telling where the sun is, was or will be (is it dark already?) are other utilities for telling the time.
Sometimes, we just want a difference. Whatever granularity is needed is what should be used in those cases. If you have enough space to spare, register the range so you won't miss information. And in those cases, the best choice is the local time accompanied with the time zone offset. Why is that so? Because that carries all the information you need to tell either the local time or the universal time. Then, you won't have problems trying to figure out the order of events when you know someone was doing something a given local time, but a pretty stupid service will tell you said person has sent a message in a time in a timezone you don't even know what it is.
As I usually deal with some network protocols, I am used to ISO8601 format as that is used in XMPP and Atom, for example. The GLib library know how to decode it and how to encode it. Unfortunately, when doing so, it totally loses the timezone information. So, it will convert an ISO8601 date/time into a timeval equivalent that does not know anything about timezones. Similarly, when outputing that timeval, it will even ignore your system timezone and output something in UTC. That's sad.
How about GNU libc? What is recommended using? gettimeofday, which returns a timezone struct, has this feature totally unrecommended for Linux. Besides, it has just been turned obsolete in POSIX. The best option to get the current time with finer granularity then the second is using clock_gettime. However, that does not solve our timezone problem.
What we have available is tzset(), which sets some external variables depending on your environment (TZ) or default zoneinfo file, usually /etc/localtime. Also, gmtime and localtime breaks down a time_t into a struct tm with the difference that gmtime uses UTC and localtime uses your timezone, by calling tzset.
So, one thing that would be good by now is to give some support for local time in GLib. Another one would be to make clear to the user of many different services what timezone they are refering to. If they have a worlwide userbase and can't let the user pick up their own local time, using UTC by default would be a plus.