if you need to create a string holding a datestamp, please — for the love of everything that’s holy and just and pure in this universe — stop abusing the patience of everyone on this planet, and use the ISO 8601 format.
formats not to use:
- seconds from the epoch – oh please. I mean: come on ((okay, I’m guilty of this insanity as well, but I’m in the process of fixing it)).
- HTTP date – which is defined in two RFCs but it still sucks for small things like sorting or, you know, non-human parsing.
- ctime() output – now, give me a flipping break
and please, don’t even think that people can rely on strptime() if they want to parse your datestamps — because they might care about something called “timezone” ((a huge FAIL should be photoshopped on top of strptime(3) man page, right near the “Glibc Notes” section, where it says that in most cases the corresponding fields are parsed, but no field in tm is changed; WTF? what does in most cases mean? you have to tell me in which cases, you fscking idiot!)).
any reference to running web services and their utter lack of clue in this matter is purely coincidental. not.
this blog post should go in the overall discussion about how web services clearly showed me how the bar for writing them has been placed so low that not even “Eleven Inches” Hermes could limbo beneath it. if even a simple, clearly defined data exchange format like JSON has been abused that much ((and I’m looking at you, Tumblr)) then there’s really little hope for the rest of us that care about interoperability and third party application development.
So, as a system programmer, I am asking you which date/time library should I be using for time stamps? Perhaps ICU (http://www.icu-project.org/), a 15+ meg library, which handles all the crappy timezones rules for all the historical dates? Something else?* No way, I’ll stick to epoch seconds until someone shows a solid and efficient implementation, thank you.
* I didn’t find any other serious C/C++ libraries (expect olson timezone lib, which doesn’t seem to be designed to be used by normal apps)
Caveat:
http://bugzilla.gnome.org/show_bug.cgi?id=535223
ISO 8601 dates are certainly nice, but for GBookmarkFile we may need to (re)generate thousands of them. In that case, strftime() causes the timezone files to be opened thousands of times.
@federico: I never saw that bug – bugzilla failed me. as I replied to michael, glibc keeps stat()-ing the timezone file while it should cache that stuff internally and reload it every hour or so – how many times in a day your timezone data changes?
@xyz: oh please. use time stamps internally and when you export it use strftime() with the UTC ISO 8601 format; unix epoch is UTC anyway. it’s a single
strftimecall. parsing is trivial and gives you UTC time stamps back.Ok, I read the spec of ISO again, and it does seem to be better than I thought (I assumed it requires real time zone handling – it only does raw offsets from UTC), my mistake.
But. It is not trivial, not if you support the whole spec and expect to run the code on weird platforms. So, is there a small self contained library for parsing/generating such dates? Until then, I’ll let the rich clients on Win/Lin/Mac convert from epoch, which IS trivial.
But without these “in most cases” APIs where would be the fun and excitement in programming? ;-)
Besides, it’s all your own fault for looking at wrong web services
@tommi-1: while I like fun challenges, I don’t like braindamage ;-)
@tommi-1: jaiku? the same jaiku that’s part of google? don’t let me start on the insanity that are google json apis. youtube is hell, just ask Chris.
@xyz: you can lift the code from glib/gtimer.c; it’s licensed under LGPLv2.1, if you care.
The right way to use ISO 8601 is to store everything in UTC time (Z timezone) in the backend, and only convert to local human time in the presentation layer on a as-needed basis.
Working in Z timezone requires no complex timezone offset processing for timestamps and can be done trivially in any program which has access to UTC unix time. And as long as this program is the only one writing the timestamps, parsing them requires no complex logic either (but the good part is a standard UTC time representation means other programs can parse them too without abiguïty)
You don’t have to support the whole ISO 8601 spec. You just need to find the ISO 8601 subset that’s sufficient for your needs. As long as you stick to this subset, everything will be fine.