Sign up Sign in Samples Blog contact support
Dates and Times in Cardnames




In order to properly represent dates and times in Wagn, we will need them to be handled in standard ways in cardnames.  This can be thought of as an extension of handling "inflections", for SmartName, that is word boundaries and plurals.


Appropriately increment dates in autoname feature



When a group of words in a cardname pattern is recognized as a date reference, the name to key mechanism in SmartName needs to always product the same canonical key so that we don't have multiple cards representing the same date value.



Starting with a reference to a day:

2013 March 3 or 2013March 3, 2013Mar.4 or 2013_march_3 all get the key => 2013_march_03

Event_on_2013_July_4 -> event_on_2013_july_04

Monthly_2013Oct => Monthly_2013_october





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!

--John Abbe.....2013-06-11 20:29:29 +0000

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?

--Ethan McCutchen.....2013-06-12 16:50:23 +0000

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.

--Gerry Gleason.....2013-11-16 16:51:46 +0000

+relevant user stories