I only recently realized that numbers make perfectly fine cardnames, but they don't behave quite like we would expect them too. I can create cards with the names: 0, 00, and 000000, or 01, 1, 0001 and they are all different cards. They only sort numericallly if you use a common with and always pad to that width.
Similarly, we can put dates into cardnames, but you need a consistent format for the dates or they all name different cards. The card name model works better if name parts that represent the same abstract thing (a number, a date or a datetime) should have the same keys.
This can be integrated into smartname. We'll need to come up with the rules for classification and the key representation. I may have a smartname branch where I was playing with this idea. My thought was to use capital letters in the first column of the key to select from a number of available key encodings. The numeric values would have to be padded to a standard maximum width. Larger values wouldn't be rejected, just fallback to the standard encoding for text strings.
+discussed in support tickets+relevant user stories