Beware of calculateDateDifference service

, ,
1

Affected package: WmPublic version 10.5.0.0.84.

calculateDateDifference service and Daylight Saving Time (DST)

Recently we had some issues in production. When I looked closer, the service pub.date:calculateDateDifference failed with the error could not be converted to a date.

That happened early morning on March 26. And yes, on March 26 at 2 AM, the time was shifted to 3 AM in timezones that use DST.

Our IS servers run in Central European Timezone (CET).

The service does not have a timezone input parameter, so it falls back and uses the server’s timezone.

The service works as expected for any dates (with time part) outside DST changes.

For example, for input parameters:
startDate: 2023-03-23 02:00:00
endDate: 2023-03-23 03:00:00
startDatePattern: yyyy-MM-dd HH:mm:ss
endDatePattern: yyyy-MM-dd HH:mm:ss

You get the correct results.

Now try to get a date difference for any date between 2023-03-26 02:00:00 and 2023-03-26 02:59:59, and you will get the error.

For example:
startDate: 2023-03-26 02:00:00
endDate: 2023-03-26 03:00:00
startDatePattern: yyyy-MM-dd HH:mm:ss
endDatePattern: yyyy-MM-dd HH:mm:ss

The service will produce could not be converted to a date error.

Well, technically, this is correct. There is no such date 2023-03-26 02:00:00 in the CET timezone, but such a date exists in the UTC timezone.

You might run into trouble using this service when calculating the difference, and one of the input dates is in UTC (our case), as UTC does not use DST.

The service should have a timezone input parameter!

Until then, you will be better off using a java service instead.

The service is a ticking time bomb that can go off twice a year :wink:

2

I was able to replicate the error for US Central time on Mar 12.

startDate: 2023-03-12 02:00:00
endDate: 2023-03-12 03:00:00
startDatePattern: yyyy-MM-dd HH:mm:ss
endDatePattern: yyyy-MM-dd HH:mm:ss

Could not run ‘calculateDateDifference’
com.wm.app.b2b.server.ServiceException: [ISS.0086.9254] [2023-03-12 02:00:00] could not be converted to a date

The timezone would be provided in the input strings.

startDate: 2023-03-12 02:00:00-0600
endDate: 2023-03-12 03:00:00-0500
startDatePattern: yyyy-MM-dd HH:mm:ssZ
endDatePattern: yyyy-MM-dd HH:mm:ssZ

With the timezone added to the strings, it works as expected. The fun part is getting the right timezone offsets-- for the 2 inputs above, the difference is 0 because they are the same time. If the endDate is -0600 (which is valid, but for another timezone) the difference is 1 hour.

As you most likely know, the date services use the SimpleDateFormat classes underneath. As such, any string parsing challenges will exist in any Java service that also uses SimpleDateFormat.

There are articles on the web that describe ways to calculate differences between times. And using newer classes in java.util.time for various needs including parsing strings. Perhaps at some point there will be new built-in services that use the java.util.time classes.

3

Hi Reamon,
you are right, we do have plans to adopt the java.util.time classes, can’t promise when though :wink:
John.

4

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.