Comments on: Chart of time.h Functions http://www.danvk.org/wp/2009-02-24/chart-of-timeh-functions/ Keepin' static like wool fabric since 2006 Wed, 08 Sep 2010 02:51:40 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Peteris Krumins http://www.danvk.org/wp/2009-02-24/chart-of-timeh-functions/comment-page-1/#comment-17641 Peteris Krumins Wed, 25 Feb 2009 14:10:29 +0000 http://www.danvk.org/wp/?p=459#comment-17641 There is another nice graph of relationship of various time functions in Advanced Programming in the Uni Environment: <a href="http://imagepaste.com/img/dab9a2e71ee652988eacb49b986fe92c.png" rel="nofollow">http://imagepaste.com/img/dab9a2e71ee652988eacb49b986fe92c.png</a> 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 http://www.danvk.org/wp/2009-02-24/chart-of-timeh-functions/comment-page-1/#comment-17632 danvk Wed, 25 Feb 2009 06:41:49 +0000 http://www.danvk.org/wp/?p=459#comment-17632 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. 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 http://www.danvk.org/wp/2009-02-24/chart-of-timeh-functions/comment-page-1/#comment-17631 Johannes Wed, 25 Feb 2009 06:32:31 +0000 http://www.danvk.org/wp/?p=459#comment-17631 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: <a href="http://java.sun.com/javase/6/docs/api/java/util/Date.html" rel="nofollow">Date</a> - represents a specific instant in time, with millisecond precision. <a href="http://java.sun.com/javase/6/docs/api/java/text/DateFormat.html" rel="nofollow">DateFormat</a> - converts back and forth between Date and Strings, considering language, locale, and type of calendar used. <a href="http://java.sun.com/javase/6/docs/api/java/util/Calendar.html" rel="nofollow">Calendar</a> - lets you do arithmetic with split-up dates, e.g. help answer the question "Is this the second Saturday of the month?"</a>. 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. 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.

]]>