Question
datetimetoBigdecimal function (com.pega.ibm.icu.math.bigdecimal)
The datetimetoBigdecimal function is returning the same results in SIT, UAT, pre-prod, and prod, but different results in DEV.
Do you have any idea why this is happening? Ex: @DatetimetoBigdecimal(20230417) = 19464 in Dev
@DatetimetoBigdecimal(20230417) = 19463 in SIT, UAT, Pre-prod and Prod
Accepted Solution
Areteans Technology Solutions
GB
@Arunkum@r This issue has been resolved. I passed the input parameter with a timestamp value, irrespective of the operator's timezone. The format used was '@DatetimetoBigdecimal(20230417T000000.000 GMT)', which resulted in the correct value of 19464.
Areteans Technology Solutions
GB
@Arunkum@r Repost
Pegasystems Inc.
GB
@Arunkum@rplease doublecheck Timezones of server and DB server, as well as java versions installed.
See:
Understanding the Date, TimeofDay, and DateTime property types
Contrasting time-qualified rules and historical processing
Troubleshooting DateTime issues
How BusinessCalendar functions AddDays() and AddTime() treat holidays, weekends, and time zones
Areteans Technology Solutions
GB
@MarijeSchillern Thank you for your response. After checking, we have narrowed down the different issues. When using the @weekday(20230417) function with the America/New York timezone operator, the value returned is 2. However, when using the same function with the Europe/Belfast timezone operator, the value returned is 1 Could you explain why there is a difference?
Coforge
IN
@Arunkum@r Can you check the calendar added in both the operators too under the work tab. Do both operator have same calendar? We use Calendar to define working days.
Areteans Technology Solutions
GB
@abhiraj yes. same calendar. The only difference between the two operators is their time zone settings Operator Profile -> Localization -> Time Zone = America/New York Operator Profile -> Localization -> Time Zone = Europe/Belfast
Accepted Solution
Areteans Technology Solutions
GB
@Arunkum@r This issue has been resolved. I passed the input parameter with a timestamp value, irrespective of the operator's timezone. The format used was '@DatetimetoBigdecimal(20230417T000000.000 GMT)', which resulted in the correct value of 19464.