pvillard31 commented on code in PR #11296:
URL: https://github.com/apache/nifi/pull/11296#discussion_r3337223473
##########
nifi-commons/nifi-expression-language/src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/PlusDurationEvaluator.java:
##########
@@ -23,18 +23,27 @@
import java.util.Date;
/**
- * Evaluator for {@code plusDuration('3 months')} — adds a calendar-aware
amount to a Date.
+ * Evaluator for {@code plusDuration('3 months')} or {@code plusDuration('1
day', 'America/New_York')}
+ * — adds a calendar-aware amount to a Date, optionally in a specified
timezone.
+ *
+ * <p>Providing a timezone is important for DST-sensitive units (days, weeks,
months, years):
+ * adding "1 day" across a DST boundary should preserve wall-clock time, not
add exactly 24 hours.</p>
*
* <p>Examples:</p>
* <pre>
* ${date:toDate('dd-MM-yyyy'):plusDuration('1 week'):format('dd-MM-yyyy')}
- * ${date:toDate('dd-MM-yyyy'):plusDuration('2 years')}
+ * ${date:toDate('dd-MM-yyyy', 'America/Chicago'):plusDuration('1 day',
'America/Chicago'):format('dd-MM-yyyy', 'America/Chicago')}
Review Comment:
The expression language guide documents plusDuration and minusDuration with
only the amount argument. Should we update expression-language-guide.adoc to
document the new optional timezone argument and add a DST example?
##########
nifi-commons/nifi-expression-language/src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions/AbstractDateArithmeticEvaluator.java:
##########
@@ -66,8 +74,16 @@ public QueryResult<Date> evaluate(final EvaluationContext
evaluationContext) {
}
final String amountExpression =
amountEvaluator.evaluate(evaluationContext).getValue();
- final ZonedDateTime zonedDateTime = ZonedDateTime.ofInstant(
- subjectValue.toInstant(), ZoneId.systemDefault());
+
+ ZoneId zoneId = ZoneId.systemDefault();
+ if (timeZoneEvaluator != null) {
+ final String tz =
timeZoneEvaluator.evaluate(evaluationContext).getValue();
+ if (tz != null) {
+ zoneId = ZoneId.of(tz);
Review Comment:
The amount literal is validated in the constructor, but the timezone is only
resolved at evaluate time. Should we validate a literal timezone at
construction so an invalid zone fails fast like an invalid amount?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
