Automate your infrastructure to build, deploy, manage, and secure applications in modern cloud, hybrid, and on-premises environments.
In this blog we will explore the complexity of dealing with date/time in general and in particular with Serverless functions (Lambda or Azure functions).
We will talk about the Universal Time Coordinate (UTC) and we will also look at how to pass date/time values in a Corticon.js decision service JSON payload.
This post is intended for users doing integration of decision services with other systems; it’s not intended for rules author.
There are quite a few issues with dealing with dates times and distributed systems in general (distributed clients as well as distributed decision services):
Here is a quick diagram showing the complexity of dealing with distributed clients as well as distributed decision services.
This scenario could be for example, a rental car service where the dates exchanged are the date of the reservation and the date/time when the vehicle is available.
Client 1 is on the East Coast of the U.S. and makes a request for reserving a car. The request can be served by Server 1, which is in the same time zone but is running in the cloud where the servers are set to UTC time anyway. As part of fulfilling the request, Server 1 makes a request to a REST service for computing a premium based on where the vehicle will be driven and to a second service to adjust premium based on the risk adjusted for the season. This REST services are running in different time zone than the client and Server 1 as well.
Client 2 is in Bermuda at UTC – 3, but its request is routed to a data-center on the West Coast of the U.S. at UTC – 7.
We can also imagine the scenario where Client 1, flies to a different city and is now at UTC – 5. The date/time computations still need to occur properly.
We quickly see how complex the situation gets and that we cannot make any assumptions of where a decision service runs, even between two successive requests.
Standardizing on UTC as a universal time coordinate starts to make sense if we don’t want to pull hair trying to make complex systems work 😊.
UTC stands for Universal Time Coordinate. Corticon.js decision services will convert all date/time to UTC time reference automatically and will do all its computations and output in UTC mode. There are many reasons to take this approach:
For some good reads on why use UTC see: The Worst Server Setup Mistake You Can Make and Always Use UTC Dates And Times, among others.
As a side note, there are similarity between UTC and GMT but technically these are different. See UTC – The World's Time Standard for more background data and differences between UTC and GMT.
UTC lets us agree on a specific time coordinate, but it does not specify the format to represent the date/time in a request or response.
JSON does not standardize how to represent dates and times. The most common formats we have seen used in services, in particular REST services, are ISO 8601 and as a number (number of milliseconds since epoch). Thus, in order to make your life easier, we decided to support these two formats right out of the box.
In the JSON payload the date/time data can be specified as either:
For example, here is how you could pass the date/time (UTC) “Thursday, July 30, 2020 6:00:00 PM” in the decision service JSON payload:
So, to summarize, here are a couple of things to keep in mind:
Here are key parameters to consider when thinking about TZ:
At the end of the day, decision services are one part of a bigger picture and the integrator has to deal with TZ no matter what. We are not really adding a new problem here. We are defining simple rules by which dates and times will work correctly.
Now that you understand the issues dealing with date, we recommend you work with UTC dates and only adjust to the local user time zone just before displaying them.
To make your life a little easier, we offer two options:
Independently of the option chosen, the date/times in the result JSON will be returned in UTC. You are left with the task of converting to the local time zone of the various devices where the date/time is rendered. Of course, this is assuming the result is directly used in a user interface, if you are chaining a decision service to another, you likely won’t need to do any conversion.
In conclusion, dealing with date/times is tricky. We tried to make the life of an integrator easier by:
Hopefully, you find this useful for integrating your decision services into your applications and as importantly, for debugging and maintaining it.
Feel free to leave a question below for any additional questions you may have.
We discuss the ISO 8601 date/time format in this related blog post, "Understanding ISO 8601 Date and Time Format."
Learn more about Corticon.js
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.