For example, using a light only within sunset and midnight. You need two conditions as of now; time and sun. Much simpler and more logical to be able to access sunset and a time in the same condition. Take a look at the UI automation and it’s simply not possible.
The Sun integration is old and making sweeping changes to it would affect a large number of users.
Two conditions is not very many conditions…
You can do it in one condition relatively easily by creating template sensors for the different attributes of the Sun integration or by using the sensors provided by the Sun2 integration instead.
What I’m suggesting is to make life easier for non-programmers. The default answer for simplification requests is “you can do this with templates” or some other complexity. Why not simply add “sun” conditions to the “time” condition? There, life is easier for the automation UI. This is a no-brainer feature request.
I get your point but if you just look at the vast (huge) amount of options people strive for (check the posts in this forum and discord and…)… it is not that easy to accommodate GUI-alike
The template solution allows (almost) anything and from what I read, you request seems to be ‘just’ a matter of 2 conditions in an automation via the GUI.
Maybe ask your question for solution and then raise a feature request (or maybe you already did)
Yes I did exactly that. Hence this request. The direction of HA is to make things easier, and UI automation is making great steps in this direction. It isn’t obvious to beginners that you have to combine conditions to get what I suspect is the most-used time condition-- sunset and a specific time. Again this should be an easy to accomodate feature and one that would be used a LOT. Pretty much all other automation platforms I’ve used in the past already have this.
First, in general, I kind of agree with you. This seems reasonable from a user functionality perspective.
Second, though, you haven’t even voted for your own request, so… 
Third, to be thorough, if this is done for conditions, then it should also be done for triggers.
Fourth, sun conditions/triggers have optional before_offset & after_offset parameters. So, they would also need to be added to the “combined” time/sun conditions & triggers. That could be generally useful, for say, a condition based on an input_datetime or sensor, where the condition/trigger could specify an offset to those as well.
Fifth, this would be a lot of work, to implement, and properly cover with tests, oh, and not to mention, update the frontend accordingly.
Sixth, it could get confusing with two ways to do sun-based conditions & triggers. The existing sun-based conditions/triggers couldn’t just be dropped, or it would break a zillion scripts & automations. So, they would require continued support & documentation, even if some sort of deprecation period was implemented.
So, although, yeah, I kind of agree (I’ll even vote for it!) that it would have been nice if it was implemented this way in the beginning, at this point, it seems like a lot of effort that could better be spent elsewhere. But that’s just my “two cents.” In the meantime, just use multiple types of conditions, which you’d have to do for the other 5 or 6 other types of available conditions.