d38377b85e
* Clarify locale-safe DateFormula Evaluate inputs Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Normalize DateFormula article sections Keep the analyzer-gap explanation in Description and its scoped probe evidence in References, without a novel Validation section. Normative guidance and fixtures are unchanged. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
3.4 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
style |
|
|
|
|
Parse DateFormula constants with language-independent input
Description
A DateFormula stores a formula in a language-independent representation, but Evaluate must first interpret its text input. Declaring the destination as DateFormula does not make an English literal such as 1W independent of the session language: French uses S for weeks. Passing the resulting typed variable to CalcDate satisfies that call's CodeCop AA0462 argument requirement, but cannot repair a parsing failure that already happened in Evaluate.
Best Practice
For an application-defined formula in a normal two-argument Evaluate call, use the generic units inside angle brackets, such as <1W>. Apply this at the text-to-DateFormula boundary, including a visible constant passed through a helper. A label's Locked = true prevents translation of its text; it does not make unbracketed English units language independent.
Preserve genuinely localized input: text entered by the user, or already formatted for the same session language, should be parsed in that language. Do not blindly wrap that text in angle brackets. Already invariant <...> literals, explicit import-format conversions, a typed formula passed to CalcDate, and Format(Interval) = '' checks are not findings without an unsafe constant at the parsing boundary.
See sample: dateformula-evaluate-needs-language-independent-literals.good.al.
Anti Pattern
A hard-coded, language-fixed formula such as 1W flows into a normal two-argument Evaluate whose destination is known to be DateFormula, and the application expects that default to work across session languages. Require the destination type and constant provenance; an arbitrary Evaluate call or dynamic text parameter is not enough. The resulting code can compile and work in English while failing when the same default is first needed in another language.
Do not report direct CalcDate text arguments under this article: CodeCop AA0462 already owns the requirement for a typed formula or angle-bracketed text there. Its typed-argument check does not establish that an earlier Evaluate parsed language-independent input.
See sample: dateformula-evaluate-needs-language-independent-literals.bad.al.
References
DateFormula data type and CalcDate language behavior.
CodeCop AA0462 defines the separate direct-CalcDate check. In a CodeCop compilation probe against BC28.5 symbols, the direct text control produced AA0462; Evaluate(Interval, '1W') followed by typed CalcDate did not.
BaseApp retention scheduling initializes a typed formula with an invariant literal.