|Subject:||Re: date grief
|Date:||Sat, 16 Dec 2017 07:24:31 +1000
|From:||Bernie van't Hof <email@example.com>
The goal here *is* a full emulation but as no-one can see the remotest
valid use case for that behavior I think it likely any use would be
unintentional, so flagging it as an error is doing everyone a favor.
I suppose in a perfect world there could be a setup flag
"support pdox query wildcard arithmetic feature: Y/N"
but gotta draw a line in the sand somewhere.
On 12/12/17 8:46 am, Leslie wrote:
> On 12/12/2017 8:03 AM, Bernie van't Hof wrote:
>> And how about:
>> CHECK calc 24-Jun-2016-2..
>> CHECK calc 24-Jun-2016+2..
>> (same result)
>> ============ Answer ==========
>> ANSWER | Date | Blank |
>> 1 | 1-Jan-2011 | |
>> 2 | 23-Jun-2016 | |
>> 3 | 24-Jun-2016 | |
>> 4 | 25-Jun-2016 | |
>> In contrast to:
>> CALC 24-Jun-2016-24-Jun-2016 => OK (0)
>> CALC 24-Jun-2016+24-Jun-2016 => "Type Error"
>> I think we're done: MATH + WILDCARD = ERROR
>> - Bernie
> Yes and No.
> *Day* arithmetic after a date pattern works, any other combinations will
> probably produce an error or do nothing.
> Having said that, I think it likely that Date Pattern + Day Value only
> works because of how the parsing works and not by intentional design.
> So without the actual documentation, I think you are within your rights
> to claim it to be unsupported in your new world. You could always
> revisit if any additional information comes to light.
> Of course if the goal is not an emulation, then you could make your own
> date parsing rules up when patterns are involved.
> This email has been checked for viruses by AVG.