Les deux points dans l'url de votre premier exemple vont provoquer une erreur (Bad Request) et vous ne pourrez pas faire exactement ce que vous cherchez. À part cela, l'utilisation d'un DateTime comme paramètre d'action est tout à fait possible.
Si vous utilisez le routage par défaut, la troisième partie de votre exemple d'url va récupérer la valeur DateTime comme paramètre {id}. Votre méthode d'action pourrait donc ressembler à ceci :
public ActionResult Index(DateTime? id)
{
return View();
}
Vous voudrez probablement utiliser un Datetime Nullable comme je l'ai fait, de sorte que si ce paramètre n'est pas inclus, il ne provoquera pas d'exception. Bien sûr, si vous ne voulez pas qu'il soit nommé "id", ajoutez une autre entrée de route en remplaçant {id} par le nom de votre choix.
Tant que le texte de l'url est converti en une valeur DateTime valide, c'est tout ce que vous avez à faire. Quelque chose comme ce qui suit fonctionne bien et sera pris en compte dans votre méthode Action sans aucune erreur :
<%=Html.ActionLink("link", "Index", new { id = DateTime.Now.ToString("dd-MM-yyyy") }) %>
Le problème, dans ce cas bien sûr, est que je n'ai pas inclus l'heure. Je ne suis pas sûr qu'il existe des moyens de formater une chaîne de date (valide) avec l'heure non représentée par des deux-points, donc si vous DEVEZ inclure l'heure dans l'url, vous devrez peut-être utiliser votre propre format et analyser manuellement le résultat en DateTime. Supposons que nous remplacions les deux-points par un " !" dans le lien d'action : new { id = DateTime.Now.ToString("dd-MM-yyyy HH!mm") }
.
Votre méthode d'action ne parviendra pas à l'interpréter comme une date. Dans ce cas, le mieux est probablement de l'accepter comme une chaîne de caractères :
public ActionResult Index(string id)
{
DateTime myDate;
if (!string.IsNullOrEmpty(id))
{
myDate = DateTime.Parse(id.Replace("!", ":"));
}
return View();
}
Edit : Comme indiqué dans les commentaires, il existe d'autres solutions, sans doute meilleures que la mienne. Lorsque j'ai écrit cette réponse à l'origine, je crois que j'essayais de préserver au mieux l'essence du format de date et d'heure, mais il est clair que l'encodage URL serait une façon plus appropriée de traiter cette question. +1 au commentaire de Vlad.