In this example of a systemd unit file:

# systemd-timesyncd.service
...

Before=time-sync.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-sync.target

systemd-timesyncd.service should start before time-sync.target.
This defines an ordering dependency.

But at the same systemd-timesyncd.service wants time-sync.target. So time-sync.target is it's requirement dependency

What is the use case for this relation and why aren't they in some conflict with one another?

The use case of this double relation is similar to a “provides” relation. systemd-timesyncd provides a time synchronisation service, so it satisfies any dependency a unit has on time-sync.target. It must start before time-sync.target because it’s necessary for any service which relies on time synchronisation, and it wants time-sync.target because any unit relying on time synchonisation should be started along with the systemd-timesyncd service.

I think the misunderstanding comes from your interpretation of “wants”. The “wants” relation in systemd isn’t a dependency: systemd-timesyncd doesn’t need time-sync to function. It’s a “start along with” relation: it says that the configuring unit (systemd-timesyncd.service) wants the listed units (time-sync.target) to start along with it.

See also Which service provides time-sync.target in systemd?

The purpose of this mechanism is to ensure that ordering relationships can be made but do not take effect unless necessary.

time-sync.target is an ordering milestone. All of the services that provide "time synchronization" specify that they are Before the time-sync.target, so that the target only becomes ready once "time synchronization" is in effect. All of the services that need "time synchronization" to be in effect when they run specify that they are After the time-sync.target.

If the latter also had a Wants relationship to that target, then they would always end up being ordered by it, as it would always be included in the set of things that are put into order.

This is seen as being suboptimal in the case where there is in fact no concrete "time synchronization" service; and the thinking of the systemd people is that such ordering should not be in effect in such a case. Rather, services should be ordered as if time-sync.target were not there, allowing some of them to be started much earlier if that is their "natural" position without the milestone.

The solution is for time-sync.target to actually not be there. It isn't wanted by the services that expect to start after time synchronization is available. So it does not exist in the set of ordered things if only those services are started. It is only brought into the set if an actual "time synchronization" service is started, with that (rather than the client services) having the Wants relationship that brings it in.

Targets do not necessarily have to be collections of services. They can also be ordering milestones.

There are a fair number of such pure milestones, in systemd and elsewhere. The name-services target in the nosh toolset's service bundle collection is a similar pure ordering milestone.

Further reading

• Jonathan de Boyne Pollard (2018). system-control. nosh Guide. Softwares.

time-sync.target is kind of a flag in system, so that services depending on a correct time do not have to depend on systemd-timesyncd, ntpd, whatever.

The Before entry tells systemd to start systemd-timesyncd, then time-sync.target (this is just for ordering). The Wants tells it to actually set the flag.