Blog Posts Case Management Process Management Process Modeling

A Strange FEELing about Dates

Blog: Collaborative Planning & Social Business

The new expression language for Decision Model and Notation standard is called the Friendly Enough Expression Language (FEEL). Over all it is a credible offering, and one that is much needed in decision modeling where no specific grammar has emerged as the standard. But I found the handling of date and time values a bit odd. I want to start a public discussion on this on this, so I felt the best place to start is the blog post here, and this can serve as a focal point for discussion references.

The Issue

A lot of decisions will center on date and time values. Decisions about fees will depend on deadlines. Those deadlines will be determined by the date and time of other actions. You need to be able to do things like calculate whether the current transaction is before or after a date-time that was calculated from other date-time values.

FEEL includes a data type for date, for time (of day) and for date-time. It offers certain math functions that can be performed between these types and other numbers. It offers ways to compare the values.

Strange case 1: Would you be surprised that in FEEL you can define three date-time values, x1, x2, and x3 such that when you compare them all of the following are true?:

x1 > x2
x2 > x3
x3 > x1.

All of those expressions are true. They are not the same date-time, they are all different points in time (few hours apart in real time), but the “greater than” operator is defined in a way that dates can not actually be sorted into a single order.

Strange Case 2: Would you be surprised that in FEEL you can define two date-time values, y1, and y2, such that all of the following are false?:

y1 > y2
y1 = y2
y1 < y2

That is right, y1 is neither greater than, equal to, nor less than y2.

What is Happening?

In short, the strangeness in handling these values comes from the way that time zones and GMT offsets are used. Sometimes these offsets and time zones are significant, and sometimes not. Sometimes the timezone is fixed to UTC. Sometimes unspecified timezones come from the server locales, and other times from the value being compared to.

Date-time inequalities (greater-than and less-than) are done in a different way than equals comparisons. When comparing greater or less than, the epoch value is used. (That is — the actual number of seconds from that instant in time since Jan 1, 1970 and the timezone is considered in that calculation.) But when comparing two date-time values, they are not equal unless they come from the exact same timezone.

It gets stranger with date-time values that omit the timezone. If one of the date-time values is defined without a timezone, then the two values are compared as if they were in the same timezone. This kind of date-time has a value that changes depending upon the timezone of the data value being compared to!

Date values, however must be the date at midnight UTC. Timestamps taken in the evening in California on Aug 13 will be greater than a date value of Aug 14! The spec is actually ambiguous. At one point is says that the date value must be UTC midnight. UTC midnight of Aug 14, is Aug 13 in California. At other points it says that the time value is ignored and the numeric day value (13) would be used. The two different interpretations yield different days for the date-time to date conversion.

It gets even worse when you consider time zones at the opposite ends of the timezone spectrum. When I call team members in Japan, we always have to remember to specify the date at each end of the call … because even though we are meeting at one instant in time, it is always a different day there. This effects your ability to convert times to dates and back.

Time of day values oddly can have a time zone indicator. This may not strike you as odd immediately, but it should. Time zones vary their offset from GMT differently at different times of the year. California is either 8 or 7 hours from GMT, depending on whether you are in the summer or winter. But the time-of-day value does not specify whether it is in summer or winter. Subtracting two time-of-day values can give value varying by 0, 1 or 2 hours depending on the time of year that the subtraction is done, and it is not clear even how to determine the time of year to use. The server current date? Your model will give different results at different times of the year. Also, you can combine a date and a time-of-day to get a date-time, but it is not clear what happens when the time-of-day has a timezone. For example, if I combine Aug 14 date, with time-of-day 8pm in California, do I get Aug 13, or Aug 14 in California? Time-of-day has to be positive (according to the spec) but this appears to add 24 hours in certain cases where the timezone offset is negative.

If that is not enough, it is not clear that the DMN model will be interpreted the same in different time zones. Remember that phone call to Japan? The same DMN model running in Japan will see a different date than the same model running in California. If your business rule says that something has to happen by April 15, a given times stamp in Japan might be too late, while the exact same time in California still hours to go.

I write systems that collect data all over the world. We correlate and process events from a server running in India and compare to one in Finland and another in Washington DC. I am left scratching my head to figure out how I am going to write rules that work the same way on data from different locations, and so those rules run exactly the same way on servers running in different time zones. It is critical that these decision models be clear, unambiguous, and run the same way in every location.

Solution is Simple

Given all the systems that support date and time, it is surprising that FEEL does not just borrow from something that has been shown to work. I take my position from Java which has solved the problem nicely. The date-time value is well defined as the epoch value (number of milliseconds since Jan 1, 1970). Then Java offers a Calendar object for all the rest of the calculations and conversions that takes into account all the vagaries of specific timezone offsets including daylight time switching. The Calendar offers calculations like converting a string representation to a date, and converting a date back to a string. This is already well tested and proven, so just use it.

First: In the DMN spec, date-time values should simply be compared by using the epoch value — the number of seconds since Jan 1, 1970 UTC. This value is already what is used for greater than and less than comparisons. The spec should be changed to do that same for equals comparison. This would make the date/time value for 3pm in New York equal 12 noon in California for that same day. This seems clearly to be what you want. The current spec says these are NOT the same time. This would give a clear order for sorting all date-time values.

Second: The DMN spec should then define a default timezone for any model. Any date or time value without a timezone indicator is interpreted to be in the time zone of the default for the model. Date time calculation (such as add 3 days, or conversion from date-time to date, or time) use a calendar for that time zone locale. A date value would then be the 24 hour period for that date from that default calendar. A time of day would be for the default timezone, and would probably handle daylight time changes correctly.

This solves most the strangeness. Since the model defines the timezone for the model, it always executes exactly the same way, no matter where the model is being interpreted. You are never dependent on the “local timezone” of the server. And, since identical points in time always compare as equal, even if those points in time came from different locations, the rules around handling time are clear, unambiguous, and “friendly enough”.

Final Note

I don’t actually know the rationale for the unusual aspects of the specification. Maybe there is some special reason for the arcane approach. If so, one might need to invent a couple new date functions to handle them along with the scheme above. I would hazard a bet that those functions would be identical to ones already on the Java Calendar object. We really don’t need to be inventing a new and incompatible way of dealing with date values. But, I will wait for feedback and see.