Closed TK182 closed 8 years ago
Hi, thanks!
Technically there is nothing stopping us from doing that, but such a change introduces a bit overhead in terms of implementation time, tests, and additional computations required by the parser to be performed.
What I recommend at this stage instead, is utility-like ToDate()
method converting datetime
literals, e.g.
server:
protected void Application_Start()
{
Toolchain.Instance.AddFunction<string, DateTime>("ToDate", x => DateTime.Parse(x));
client:
<script>
ea.adMethod("ToDate", function(x) {
return Date.parse(x); // return milliseconds at client
});
usage sample, e.g.
[AssertThat("FinalDate > ToDate('2016-04-27')")]
public DateTime FinalDate { get; set; }
Looking at the sample above, there is no guarantee though, that every input string which is parsed by JavsScript Date.parse(dateString)
is parsed by .NET DateTime.Parse(string dateString)
as well. Most likely not, because in remarks of both implementations (at MDN and MSDN) there is an information that input string, despite the fact being basically a string representing an ISO 8601 date, may accept also other formats, but with more or less unexpected parsing results.
Due to the concerns above this ToDate()
method is not built into EA toolchain (maybe it should be?).
Obviously you can restrict accepted literals to be of some specific format, e.g. by applying additional security regex checks inside shown implementations. But as far as you're aware of what literal you're providing, this restriction seems to be redundant.
Thank you so much for the insightful and prompt answer.
I completely understand about the overhead a date literal would add. As such, the ToDate method is great solution that's easy to implement and extend.
Thanks!
ToDate(dateString)
method supported in v2.7.2 (https://github.com/jwaliszko/ExpressiveAnnotations/commit/5e81ae4b8902d2a59072824bdc6cc22ef302513c).
Great job on this project.
Would it be possible to add Date/DateTime/Time literals in the expressions?
Thanks