I would suspect that Ctrl-; isn't possible. Before going into why, let me discuss what is possible.
bindkey -s '^;' '`date +%y%m%d | perl -pe chomp`'
Just take the "c" off of your attempt to use Ctrl-O, and it works fine.
The tcsh command probably does not support Ctrl-;, which is a very sensible design, because tcsh is meant to work with a traditional Unix terminal (or some software which behaves similarly), and traditional Unix terminals don't support Ctrl-;.
So, why don't Unix terminals support Ctrl-;?
The main point for all of these Ctrl sequences was to provide an easy way to type/represent the first 32 ASCII characters because those characters do not have easily type-able characters. The straight-forward equivalent to Ctrl-; isn't all that challenging to type without the need of a Ctrl sequence, which is why no special Ctrl character (like Ctrl-;) is commonly supported.
I will elaborate. First, I'll note that much of this answer was made referencing some information I documented, about Ctrl Sequences, on my website at ][CyberPillar][: Ctrl Keyboard Sequences.
One of the rules for Ctrl characters is that if you hold Ctrl and press a character with an ASCII value of 63 through 95, you'll end up with the character that has 64 less of an ASCII value than the character you pressed. (Yes, 64 is subtracted from 63, if applicable. That gets discussed more later.)
Another rule is that if you hold Ctrl and press a character with an ASCII value of 96 through 122, you'll end up with a character that is 96 less than the character that you typed. As a result, Ctrl-Shift-A (upper-case letter) and Ctrl-a (lowecase letter) will end up with the same character. That's why if you press Ctrl-c, you may see Ctrl-C echoed back. The terminal converts the ASCII 3 to a string representing Ctrl-C when preparing the output message, ignoring the fact that you pressed Ctrl-c to generate the ASCII 3.
; (Semi-colon) is ASCII 59, which is not ASCII 64 through 95 nor ASCII 96 through 122. Therefore, the rules that were just specified (covering ASCII 63 through 122) do not provide any common interpretation for ASCII 59 (to cover Ctrl-;).
One value, which feels like an exception, is the commonly supported rule, which is for Ctrl-?. If Ctrl-; did have a common interpretation, then the common interpretation would probably follow the same pattern as Ctrl-?. The ? character is ASCII 63. So subtracting 64 from 63 yeilds -1, which basically equates to 127 with an underflow condition, which can be ignored. The result is that Ctrl-? keystroke combination effectively ends up adding 64, so 63 + 64 = 127. ASCII 127 often corresponds to the Delete key, which may be challenging to represent since the Delete has a common special behavior (which is to delete text). So ASCII 127 may frequently benefit substantially by having a commonly supported Ctrl sequence. This way, a person can type the ASCII 127 code relatively easily, by using the keyboard sequence.
Following that pattern (of adding 64), Ctrl-; would result in ASCII 123 which is a left curly brace ("{"). People did not support Ctrl-; as a common standard way of typing { since { has its own relatively-easy way to enter it on the keyboard (which is by pressing Shift-[).