So how do computers deal with dates before The Beatles' Abbey Road was top of the UK album² charts?

Negative numbers! Most modern computers can deal with dates far in the past and, hopefully, far into the future. Again, for boring technical reasons, lots of computers can only save files with a date no earlier than 13th December 1901³.

When you download a file from the Internet, the sending server can tell you when that file was last modified. That's useful if you only want to download the file if it has changed since you last got it.

It presents the date using RFC 1123 format for reasons which are lost to the ages.

< Last-Modified: Wed, 09 Oct 1940 16:45:49 +0100

Great!

If you use the venerable wget utility, it will happily save the file on your disk and tell you that is when it was created.

But what if you use curl -OR to download the file? The -R option says:

Make curl attempt to figure out the timestamp of the remote file that is getting downloaded, and if that is available make the local file get that same timestamp.

THIS IS A LIE!⁴

If curl sees a date with a negative time, it pretends that the past doesn't exist and that what you really wanted was to save the file with today's date and time.

Why does it do this?

I think it is because this code only checks for times ≥ 0. Which, I guess, is pretty reasonable. There weren't many computers around before the 1970s⁵ so the chances of finding a file which predates disco are slim.

Should we storm the barricades and demand this temporal anomaly be rectified?⁶ Nah. I've raised it as a discussion item on curl's GitHub.

If you have strong opinions about this - please join in the discussion⁷.

And, as of last week, features a small contribution by me!

Look, I'm not an experienced bit-twiddler. I can't micro-optimise algorithms or spot intricate C-based memory leaks. What I can do is get annoyed at poor documentation!

You see, documentation and code comments are vitally important. Poor spelling might trip up non-native speakers, bad examples confuse learners, and ambiguous wording is a barrier to understanding.

As was written by the sages:

a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Abelson, Sussman, and Sussman Structure and Interpretation of Computer Programs

So, what did I fix? A few years ago, I noticed Google's documentation used example domains it didn't control. The same thing was happening in the curl source code.

One example domain used was "HTTPS://your.favourite.ssl.site" - when that code was written 23 years ago, the .site TLD didn't exist. Now it does.

Is there a serious risk that someone will register ssl.site and use it to take over the machine of anyone who unthinkingly follows that example? Probably not. But it also isn't terribly clear that it is an example. So I changed it to secure.site.example which uses the reserved .example TLD.

That should make it clear to everyone that it is a placeholder example and will prevent anyone from misusing that domain.

Similarly, there were a few comments which used domain.com as an example. However, that's a real website - so I updated those to example.com.

I was delighted to see the changes accepted.

And I was only slightly disappointed to have narrowly missed out on being contributor 1337, but being number 1342 ain't so bad 😄

You can see the full list of changes on GitHub.

Much like my patch to the Linux Kernel this might be considered a trivial matter - but I honestly believe that clear and accurate documentation can be as important as the code itself.

Huge thanks to Daniel for creating curl, for making such a welcoming environment for new contributors, and for handing out such brilliant stickers at FOSDEM!