>>Adding more characters to the coding string may actually shorten the result even more - like adding lowercase, accented etc.
>
>One problem with using the upper 128 characters in the extended ASCII set (i.e. character codes 128-255) is some of those characters are used as "lead-in", "shift-in" and "shift-out" character in various Asian languages (that is if the field in question is regular character field rather than binary character). I'd run into situations where a string literal containing characters in the upper 128 codes (entered using ALT+nnn keyboard sequence) would work OK in English (and likely other language using Latin character set), but when you switch the non-Unicode configuration to something like Chinese, Japanese, or Korean you end up with either a syntax error or an error indicating a non-terminated string constant (which one of these errors is dependent on the context where the string literal appears). The most confusing bit is you get these errors in a compiled program. On the other hand, if you replace the string literal with expression like CHR(nnn), the error does go away.

You can set the field as binary, i.e. nocptrans, then it's not checked for being printable.

This is one of those cases where we want to both hold it tight and fart. Want to pack a datetime into a smallest possible string but perhaps make it still not binary, eh? Otherwise, if we stick to the binary, two bytes cover the distance between {^1980-01-01} and {^2159-06-06} (and 15 bits cover it until 2069), and the number of seconds in a day takes 17 bits. So we really need 33 bits to cover 179 years in seconds precision.

Now the solution to squeeze such a value anywhere between this tightest format and a printable (ie. human readable) format is up to whoever implements it.