It's not clear to me exactly what this is for but it feels like it may be useful, so I'll just dive in. As usual, user stories would be helpful.
My first impulse is to suggest that if you want a date / time as a card name, it be a separate part of the name. So your first example is fine (I assume the 4 in "2013Mar.4" was a typo), but the second example would become "event_on+2013_july_04" and the third would become "monthly+2013_october". Our shift from + to / will be confusing in dates, but c'est la vie.
That third example raises the general issue of handling recurring dates well, already mentioned in upgrade Date cardtype. Not sure what "monthly+2013_october" would mean though, did you mean something more like "monthly+04" (every month on the 4th), or "monthly+first_friday" (the first friday of every month) ?
And of course we want to handle ranges as well, maybe something like "2013_july_04+2013_july_07+range" ?
And then sometimes you want to specify a recurring event within a certain range!
I'm going to ramble a bit here, because, while it feels like we're not very close to an elegant solution yet, I don't feel like it's super clear for me either.
Gerry, I'd want to hear more about why you think "Event_on_2013_July_4" is a date/time. It seems more like representing an entire relationship in a simple name, which seems complicated and very unwagny. Our current solution is more like having a card for the Event, and then have the date (+date) be an attribute of the event. I actually think that's right, but the big difference is that I think the value should be a reference to a cardname (for the reasons Gerry suggests).
As for the key, it seems like it should be strictly numerical, as that's more i18n friendly.
To my mind, not only do we not want to conflate relationship handling with this naming, but nor should we conflate ranges. if you're representing the timespan from A to B, then A and B should be separate names. That's consistent with what John suggests, but his solution sounds like the mistakes we made in pre-pointer Wagn. If your event E has this range, then it should be represented as something like E+start = A and E+end = B. Of course, we might want awesome interfaces for dealing with these things, but I don't see a ton of value in trying to turn words into sentences. Perhaps that's why I haven't yet tackled German :)
You could make the case that if we're atomizing we could go down further and represent months and days and such as individual cards. That will be necessary for recurrence anyway. Then what: is each of these a cardtype?
Gerry, I hear that you want some of this functionality yesterday, but it's very complicated and so far our solutions sound 1/50 baked to me. My take is that namespaces will be helpful with this, and I haven't heard anything to suggest there's much value in upping the priority here and slowing the deeper priorities down. Is there really good reason to drop stuff and work on this?
Seems that I forgot this card was here when I created this one Dates in Cardnames, which is a little different. I agree that the date parts should be simple card name parts.
Also related is maybe handling numbers as name parts in a special way. I agree about the level of "baking" needed.