Not sure if bug: DateTime as function parameters #438
|
My current application uses version 3.13.1 and this works there. I attempted to update to version 5.4.2 and I'm running into an issue that I'm not sure if it is a bug, or just a difference in how things work now. I thought I'd ask before I opened a bug. Quick, minimal code: This one returns This one returns If I put some quotes around the date, I don't get a parsing error, but of course my function doesn't work because it is now a string. It seems like the parser doesn't like the #DateTime# parameters. |
Replies: 1 comment 5 replies
|
There was a change made in may-june that changes how dates are parsed. There's current culture taken into account now. The code in ncalc/ncalc is bound to the current culture, as it seems. In my fork, you can choose between built-in separators, current culture, specific culture, or custom separators. The order is customizable as well. |
|
Thanks. Yeah, I see the issue: It would be nice if it could handle "/" and "-" as date part separators. In addition, I noticed the time part doesn't support fractions of seconds either. That's unfortunate. I guess we lost some flexibility on the quest for more speed. |
Date separators are supported according to specified Culture
You're welcome to contribute to this feature |
|
Apologies if my tone came across wrong. I'll see about contributing support for fractions of a second, it should be straight forward. However, regarding the date formatting, since it is tied to culture so closely, I'm not sure how or how welcome it would be to handle multiple separators at one time. I feel like any way I added support for a "fallback" separator would feel like a hack that might not be something you'd want in the code. (Understandably) I'll take a look and give a couple things a try and throw some ideas out before submitting a PR. |
You can use the version I referenced - everything you mention has been implemented there in May-June. |
|
I'll take a peek, thanks |
There was a change made in may-june that changes how dates are parsed. There's current culture taken into account now. The code in ncalc/ncalc is bound to the current culture, as it seems. In my fork, you can choose between built-in separators, current culture, specific culture, or custom separators. The order is customizable as well.