Older blog entries for cdfrey (starting at number 73)

Time Conversion: timegm()

    redi, thanks for the pointer to timegm(). Both GNU and BSD, you say? Nice. I did not know that function existed.

    It would still be nice if timegm() was in a library of its own instead of libc. But that's probably asking too much.

    Good to know. Thanks!

Syndicated 2010-05-05 13:39:29 from Chris Frey's Blog - Entries tagged advogato

Time Conversion: ISO timestamps, mktime(), and UTC

    In the C library, there is a very handy function called mktime() which takes a struct tm pointer, pointing to time data in the local timezone, and converts it to a unix time_t.

    There is also a very handy set of functions that goes in the other direction. The function gmtime() takes a time_t and converts it to a struct tm in the UTC timezone. And localtime() does the reverse of mktime(), converting a time_t to a struct tm in the local timezone.

    The one function missing is the reverse of gmtime().

    One way to do it, via standard library function calls, is to adjust the TZ environment variable to "UTC" and then call mktime(), which will then use it as the current timezone. But that gets messy. Not only do you have to save the old TZ setting to restore it afterward, if your program uses threads, messing about with the global TZ variable is hardly safe.

    Another way to do it is to use gmtime() as a reference point, and loop while adjusting the original struct tm until mktime() + gmtime() gives you the result you started with. This is brute force and inelegant, but it manages to do the job without fiddling with the global environment.

    When parsing ISO timestamp strings, this problem is hit pretty quick. An ISO timestamp can contain a time in either the local timezone or UTC, depending on the trailing 'Z' flag. In my research, it does not appear that more specific timezones can be specified in the timestamp format, so at least we only have two states to worry about.

    After much searching, I've ended up with something that I find suitable enough to release. I tackled this problem back in 2007 for the OpenSync project (you can see similar code in the opensync_time.c file), but looking back on it now, the code is not clean enough for me to reuse very easily. And even though there's a vtime2unix converter function, it leaves the burden of timezones to the user.

    I took a look at Boost's date_time library as well, and while huge and comprehensive, and though it breaks the problem of time, dates, and durations into nice manageable chunks, it seemed to reverse the status of the C library: it made UTC conversions easy, and local timezone conversions hard. And it reads timezone information out of CSV files... I don't want to have to maintain my own timezone database when the OS does it for me.

    So, if I don't want to write my own conversion routines, and if I don't want to maintain my own timezone database, I'm stuck with the C library method, and the first two solutions. Might as well make it easy to use.

    The source files for TzWrapper contain the following utilities:

    • iso_to_tm() - simple ISO timestamp converter
    • utc_mktime() - the brute force UTC to time_t converter
    • TzWrapper - C++ wrapper class for setting and restoring TZ

    Using TzWrapper, it's now possible to do things like:

	struct tm pacific_tm = { ... };
	time_t t = TzWrapper("Canada/Pacific").mktime(&pacific_tm);

If you have any further tips to make this code better, or pointers to better libraries that make this code obsolete, please let me know!

Syndicated 2010-05-01 22:37:19 from Chris Frey's Blog - Entries tagged advogato

Predictions Beyond 2012?

	for those people who may not be aware: 2012 is the time which
	all the prophecies in all the religions point as being a "key
	pivotal moment" in human spiritual development. there are _no_
	predictions beyond that point, because the decision of where we
	go, and what we do next, is to be made *globally*, as an entire
	planet and a species.

With respect, I believe you may have overlooked at least one religion. :-)

There is no starting date that I am aware of in the book of Revelations. But there is a time period predicted, commonly thought to be 7 years, in which things happen that have not happened yet. So even if those 7 years started right now, the predictions would take us beyond 2012.

If so, then how can your claim be true for "all the religions"?

Syndicated 2010-04-24 02:29:46 from Chris Frey's Blog - Entries tagged advogato

Blog now syndicated

My main blog has, for many years, been right here on Advogato. But due to its focus on free software, I always hesitated writing about topics that strayed too far afield.

I've now moved my main blog to http://foursquare.net/cdfrey/blog/, and syndicated all entries with the "advogato" tag to show up here.

I plan to check the recentlog regularly, so feel free to reply to my blog posts on advogato as usual.


Syndicated 2010-03-13 22:13:29 from Chris Frey's Blog - Entries tagged advogato

I'm chuckling as I wonder if syndicators etbe and apenwarr realize they are back-to-back in the recentlog.

"We're so plugged into the consumer entertainment industry that we don't know what's going on in the world. We know all about Johnny Depp and Angelina Jolie and U2 and The Family Guy, but we don't know the laws that are being passed in our countries. We don't know about the injustices of our social systems. We don't know where our food comes from, or the suffering required to get food onto our table. We don't know about the people in our neighbourhoods who are writing books and making movies and putting on plays and singing in choirs and running garage bands. Just like the citizens of The Matrix, we are mostly oblivious to reality, in part because somebody has convinced us that consuming entertainment is a worthwhile pursuit."

- Paul Nijjar, Adjacency Matrix

Forcing signed git tags

    vicious writes with annoyance about Gnome's git setup that requires tags to have a GPG signature.

    I think the reasoning should be viewed as less of a security measure for the source tree itself, and more of a best practice. Consider it a kindness extended to your end users.

    Developers who commit to a tree are often familiar with the code. Those that are truly involved in a project may read every commit that comes in. They know what the code is supposed to do, and how it works. They know who the other contributors are, and they are in the best position to spot defects, bugs, or security holes.

    The end user has none of this advantage. In most cases, he doesn't even know where the source code is. He wouldn't know how to read it if he did. And he may not know a good patch from a bad one, nor have the time to figure it out.

    How do you bridge this chasm? The most practical way is to have a string of GPG signatures from the developer to the end user, and make it easy for the end user to verify this.

    So, the developer signs his release with his GPG key. The distro packager checks this key, builds a package, and signs that with his own GPG key. And the end user downloads the updated software with the packaging tool, which automatically verifies the package signature. A very friendly verification chain from developer to end user.

    So the question is: if you're not willing to sign a tagged release of your software, should you be in charge of releasing the code to end users at all?

Ontario Linux Fest 2009 - Advanced Registration Closing Today

    A quick heads-up to those who haven't registered online yet. Richard Weait announced that today is the closing day for the $40 advanced registration. If you miss today, it's $60 at the door.

    You can see an updated list of presentations on the website. This year's fest is packed full of FLOSS goodness.

    Hope to see you there.

Ontario Linux Fest 2009: Presentations

    A quick update to point everyone to the growing list of presentation topics for this year's Ontario Linux Fest. The list is happily large, and will get bigger.

    If you see any topics that grab your interest, remember sign up online to get the early bird rate.

    Hope to see you there!

Ontario Linux Fest 2009 - Update

    Registration is open! It has been open for a few weeks now, and I've just gotten around to announcing it in my blog here now. Apologies.

    This year's event is being held on Saturday, October 24. Just 3 weeks away! If you register in advance at the website the cost is only $40. If you show up at the door, it is $60. Earlier is better.

    If you would like your name in lights, and would like to help sponsor the event, you can become an individual sponsor as well. More details on the registration page.

    As usual, there's a welcome party on Friday night, and an after party Saturday night. Let us know if you can join us by checking the party options during your registration.

    You can see a partial list of speakers here. The final list and schedule is still in progress, and if you want to submit a presentation topic proposal, there's still time to get it in under the wire.

    The official Twitter feed for the Ontario Linux Fest is @OntarioLinux. We're using the group tag #oglf09. The 'g' is for GNU.

    You can also follow me personally on Identi.ca as @cdfrey. I may post there from time to time as I work on the show guide.

    Hope to see you at the Fest! I'll update this blog more regularly as more news becomes available.

64 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!