We have a module in an application where users define time periods for different criteria that will be used later to filter some lists.

By default each criterion applies anytime. Its validity can be limited by both restricting the application time periods, and adding exclusion time periods. Already defined application and exclusion periods can be edited or deleted.

The current interface is as follow:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Users find difficult to understand the logic of "application" vs "exclusion" time periods, which I totally understand.
I still don't find a solution to simplify the interface while keeping all the existing possibilities.

What can be done to improve users experience here?

Try showing them visually, as they build the restriction and exemption times. With each criteria added, the visual timeline updates.

I'm not sure i fully understand your use case, but it sounds like users need to clearly see the results of their restrictions and exceptions. I'm focusing a little bit on how to see the outcome as feedback.

Forcing them to read and calculate dates (and proportional allocations) seems to add to their workload. Plus it seems like they have to look at periods across each criteria as well.

Could you have a visualization that aids in showing them as they add criteria?

A heatmap example:

Github is an example of showing a years worth of data in a visual format. At a glance, you can see periods of activity.

So, instead of making them read, you can give them some visuals in tandem.

If there's another state (i'm not too clear on this): that of unrestricted and undeclared time, the heatmap can show these gaps as well.

I hope I am not misunderstanding your needs, but my recommendation is to do away with the exception/exclusion periods, as they are merely reinstating the default (criterion* applies) in a period of "restriction" (criterion does not apply). Intuitively it might appear simpler to say (as in your 3rd example) "The criterion should apply all year, except for a summer break", but you need two lines to say it, and you might as well say (in the same space, without the mental calisthenics):

Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31

To allow insertion of an exception more easily, I would recommend a split (or similarly named) button (in addition to edit and delete), which would double the current line and prefill the start of the first and the end of the second line with the start and end of the original line. A color-coded calendar to help visualize this (as suggested in other answers) would certainly be helpful but is not strictly required.

By the way, your example criterion 1 is simply the equivalent of Applies from -infinity to infinity.

*) "Criteria" is the plural of "criterion" (a standard or a trait) or of "criterium" (a bike race).

Instead of placing action buttons at the bottom, place "Add" buttons in each section.

Applies:
From 2019-01-01 to 2019-12-31 edit delete

+ Add

Except:
From 2019-07-14 to 2019-08-15 edit delete

+ Add

Overlap of rules

I apologize if I misunderstood the ASK, but I feel this is a classic case of AND & OR operations (kind of :P).

1. Users add a rule (set up time period) i.e Application


2. Users can add another rule on top of the above rule i.e Exception, which may or may not overlap with the set time period.

Since the application and exception are closely tied to mental map when creating, instead of giving them separate heirarchies I feel they should have parent/child relationship.

My proposal

I love how Zapier visualizes the AND/OR operations.

In close to the above design, your interface can look like

Usually simplifying the copy language helps (something like "add valid time range" & "block specific dates".

A second option would be adding colors such as green (for restricted times) and red (for exception times), following the logic:

Green => go, Red =>stop

A third option is to add an icon (+ for add, - for restricting).

Best if you do all three together, this makes sure you cover more users' logics (i.e. graphic-oriented vs readers) Try to think of the user as if you were talking to a kid ;) this always helps me!