Bash - 10

Well there have been a couple of answers that have been disqualified because they rely on the year, and the question very specifically states that I can not depend on 2014 being the current year. I instead rely on it being 8:14pm in my timezone.

date +%H%M 

It will work just as well in (exactly) a years time. Of course in a years time you could also run:

date +%Y --date=last\ year

This instead relies on it not being 2014.

Bash - 10 (or 8)

Well there have been a couple of answers that have been disqualified because they rely on the year. When golfing, one side goal is to see how close we can get to breaking the rules as currently written without breaking the letter of the rules (I include the clarifications by Joe Z in the 66 existing comments on the rules). The question very specifically states that I can not depend on 2014 being the current year. I instead rely on it being 8:14pm in my timezone.

date +%H%M 

When I ran it, it output 2014 exactly, thus it satisfies it No, it has to be 2014 exactly. comment. (Due to context people seem to misread it as ... 2014 always, but that was not what was written, even if that were perhaps what was intended.) This lets me beat the current Bash record, at least until this loophole is closed. This interpretation may seem too cheaty since all the existing popular answers assume that the rules really meant always. Indeed some of them exploit this and export something that isn't exactly 2014, but instead contains 2014. I am fine with that interpretation too since Bash can do:

cat /*/*

This is a mere 8 characters, which will concatenates a bunch of files including /dev/urandom/, and it generally takes my machine under a minute to find 2014 in /dev/urandom. Although my rule twisting golfing code of honour won't let me pick this solution since it violates the letter of Joe Z's clarification, the only objection Joe Z raised to the random approach in the 66 comments was that it was too long. At 8 characters this answer is actually shorter than my rules-lawyer answer.

Produce the number 2014 without any numbers in your source code

Bash - 10

OK, these may not be the best solutions, but perhaps they are at least stupid in amusing ways.

cat /*/ur*

Does it generate 2014?

$ time bash -c "cat /*/ur*|grep -o 2014|head -n1"
Binary file (standard input) matches

real    0m3.005s

Apparently it does. Normally dumping /dev/urandom would be way too slow, but 2014 only requires testing about 4 billion possibilities, which is nothing to an i7! On my machine cat /*/*, du / and apt also work. It could have been an answer before the clarification that trailing junk wasn't allowed. Alas it is not, so instead I do:

date +%H%M

The question very specifically states that I can not depend on 2014 being the current year. The legal principle "The exception proves the rule" means that that the general rule is that using date is fine. So I deduce that I may rely on it being 8:14pm in my timezone. It will work just as well in (exactly) a years time. Of course in a years time you could also run:

date +%Y --date=last\ year

That does not depend on it being 2014, instead it depends on it not being 2014. Indeed, it will begin to work the precise moment it stops being 2014. As programmers we know order of operators is important this answer does not violate the rules. This is about as close as I can get to breaking the rules without technically breaking them.

Bash - 10

Well there have been a couple of answers that have been disqualified because they rely on the year, and the question very specifically states that I can not depend on 2014 being the current year. I instead rely on it being 8:14pm in my timezone.

date +%H%M 

It will work just as well in (exactly) a years time. Of course in a years time you could also run:

date +%Y --date=last\ year

This instead relies on it not being 2014.