Yes and no.
Yes, by abstracting external dependencies, you ensure that you can easily switch between different libraries. If there is a simple and straightforward way to wrap your library; go for it.
If you can draw up a simple interface which encompasses all of your interactions with the date structure; stop reading here and go create it. The rest of the answer is mostly only relevant in cases where such an interface leads to a prohibitive complexity or amount of effort to create.
However, when such an interface is getting too complex to wrap, this can become an exercise in duplicating the library's interface. This is where you need to make a judgment call. Is the effort of abstraction worth the reduced effort if and when you switch libraries?
In cases which require a high upfront effort and with a low chance of ever needing to swap it out or maybe even a low increase to the effort needed if you do end up changing libraries; it becomes less interesting to go through the effort of abstracting from the get go.
However, I've read/heard that it's a good idea to only use what the language offers in domain layer.
Yes; but reasonable arguments can be made that some libraries extend the "stock" language up to a point where it's considered as (and intended to be used as) a near-native part of the language.
One such example are architectural frameworks such as .NET. Technically, it's something outside of the scope of C# by itself. But in reality, there's no point in separating the two. Such frameworks cannot be reasonably abstracted, they function as the backbone of your application.
Similarly, the same argument can be made for specific libraries that are ubiquitously used as "the default". Coming from the .NET world, Newtonsoft (JSON serializer), Mediatr (mediator pattern implementation), NodaTime (improved DateTime implementation) come to mind.
This is a judgment call, and it hinges on whether you consider that date library to be part of your application backbone, or as an external dependency that you want to be able to swap out at your leisure. In the latter case, abstraction is required. In the former, it is not.
This is a hotbed for discussion, which boils down to where everyone subjectively draws their own line on purism. Some will take the stance that all libraries should be abstracted - and there's no point in arguing this when you draw your purism line differently from them. Different strokes for different folks.
There is no one true answer here. You have to make a judgment call based on the practicality, effort, and expectation of future maintenance.