Comments on: Chart of time.h Functions

By: Peteris Krumins

Peteris Krumins — Wed, 25 Feb 2009 14:10:29 +0000

There is another nice graph of relationship of various time functions in Advanced Programming in the Uni Environment: http://imagepaste.com/img/dab9a2e71ee652988eacb49b986fe92c.png

By: danvk

danvk — Wed, 25 Feb 2009 06:41:49 +0000

Thanks for the info, Johannes, I’d forgotten about the Java Date API. It looks like .NET also avoided the historical baggage of the C Standard Library.

As you say, my alternative wouldn’t be quite as efficient. The existing time.h functions are all quite simple to implement (maybe with the exception of strptime). But I think we’re at the point where that complexity is tiny compared with the developer cost of a confusing API. If an application like crond needs the speed, they can work something out.

time.h has certainly evolved too: witness the new critters like asctime_r, ctime_r, gmtime_r and localtime_r.

By: Johannes

Johannes — Wed, 25 Feb 2009 06:32:31 +0000

Nice rant. To actually implement parsetime / formattime, you might need to split up the time_t value into its components, which you'd then interpret according to timezone etc. to make time_t. And in case your application (e.g. crond) needs to do hour/day/... arithmetic, your splittime implementation will need to undo that interpretation, so your proposal doesn't let you write the fastest code possible (or perhaps I'm a bit confused). Maybe not critically important these days, but as you note, the original library has been around. It might be interesting (or amusing, depending on your perspective) to look at how Java ended up providing this functionality: Date - represents a specific instant in time, with millisecond precision. DateFormat - converts back and forth between Date and Strings, considering language, locale, and type of calendar used. Calendar - lets you do arithmetic with split-up dates, e.g. help answer the question "Is this the second Saturday of the month?". Of course since it's Java there are more classes beyond this, and in practice the JVM still picks up some environmental settings from the OS. As far as problems and bugs with go, it should be about even with Python etc. in this area, but it sure is a bit more complicated. Witness the amount of deprecation in java.util.Date and the comments at the top; perhaps this demonstrates that it's actually somewhat nontrivial to make a nice API for dealing with time.