It's a good idea to set a short expiration time on your PGP keys for at least three reasons:

1. It slightly mitigates disaster if you should lose control of your keys, since they will be usable only for a set amount of time. So you hope that nobody will figure out how to use them before they've expired.
2. It tells other people you're actively maintaining your keys. Someone whose keys are set to expire five years from now might not reply to your email, but someone whose keys are always set to expire "a month from now" is more likely to still be active online.
3. It lets you flex your GPG muscles, so your skills don't go stale if you don't use them for a while.

It's also a good idea to use subkeys. This means even if disaster strikes and your keys are leaked, you can revoke them immediately with your master key. That's a little inconvenient because it requires you to have access to an airgapped computer any time you want to do an operation that requires the master keys, but the increased security might be useful. I'm not quite that strict, so I tend to import my master keys on my regular computer, but I do keep them on there for as short a time as possible. I'm more worried about user error than legitimate malware hunting for my keys.

That said, I'm incredibly forgetful. I set my keys up three months ago, and now they expired. I had no idea how to deal with that anymore, so I had to grep my bash logs and piece together stuff with some Google searches. Here's a checklist that applies to my subkey setup, mostly for my own sake.

Renewing Subkeys

1. Delete your secret keys. (This is because GPG refuses to import the master key if your keyring contains your subkeys.) (This step is not necessary if you have an airgapped computer dedicated for dealing with your master key.)

   gpg --delete-secret-key <email>

2. Import your master key from whereever it's stored (ideally offline somewhere.) (See above regarding airgapped computer.)

   gpg --import <master key>

3. Change the expiration date (using the command expire) on all keys. Select subkeys with key <n>. Save your changes with the command save.

   gpg --edit-key <email>

4. Export the renewed master keys.

   gpg --export-secret-keys --armor <email> > <filename>
   gpg --export --armor <email> > <filename>

5. Move the exported master keys to a safe place (ideally offline somewhere.)
6. Change the passphrase on your secret keys to something other than the passphrase for the master key. (The order here is critical: you want the exported master keys to have the master passphrase, but the exported subkeys to have a different one.)

   gpg --edit-key <email> passwd

7. Export all subkeys.

   gpg --export-secret-subkeys <email> > subkeys

8. Delete all secret keys, to remove the master key from your system entirely.
9. Import your subkeys again, now that the master key is gone. (If you're doing this on a separate airgapped computer, import your updated subkeys on the work machines where you want the subkeys.)

   gpg --import subkeys

10. Import the new public keys exported as a part of the master key export process

    gpg --import <public master key>

11. Send the public keys with the new expiration date to your key server.

    gpg --send-key <key id>

Update on 2017-06-06: it appears Debian has a newer version of gpg now, which simplifies subkey management; when I followed the above steps to update the expiration time on my keys, my gpg emitted some info messages that made it sound like it was ignoring steps that were previously necessary. I'll have to dig into this eventually, but an overview of what I suspect:

1. Step 1 appears not to be necessary anymore. It appears as though gpg will import secret master keys even if the secret subkeys exist on the system already.
2. Step 6 appears not to be necessary anymore. It appears as though subkeys can have different passphrases to their master keys these days, and gpg will remember those for you even if you import the secret master key.
3. Step 7 and 9 might not be necessary anymore. It might be the case that gpg allows you to delete the secret master key while keeping the subkeys (by modifying step 8 somehow).