I'm not sure what you expect to happen, but your rule technically has time as (part of) a conditional, not a trigger. Therefore, nothing will (necessarily) happen at sunset-30 or sunrise+15, so I'm not sure what you mean with that it "triggers correctly." Would I be correct to assume that you're saying this particular condition (time between sunset-30 and sunrise+15) evaluates to true (which will show as "(T)" here--the big "[TRUE]" is for that entire conditional, which as written would also necessitate this part being true) when you are outside that timeframe?
If so, there are a couple things you could check. Do your sunrise and sunset times look accurate before you manually click "Update" in your location settings? Second, keep in mind that the rule page will not dynamically update. If you want to re-evaluate your conditionals and see their true/false values at the current time, you'll have to reload the page--in other words, make sure the issue isn't that everything's fine and you've just had the page open for a while.
Finally, I know you didn't ask for advice on this rule in general, but the actions are a bit odd and likely have some side effects you haven't considered. Right now, they'll turn the lights on every time the sensor sends a "motion active" event, then schedule and event to turn them off 3 and 12 minutes later. Most people would want the "off" thing to happen after motion goes inactive (and stays there for that amount of time). Nothing will cancel this future/delayed "off" action, so you'll be in the dark, even if you're still in the room making motion.
To address that: the Rule 4.0 docs contain a basic motion lighting example that is more or less what you're looking for if you want to use Rule Machine for this automation, otherwise the built-in Motion Lighting app can also handle this with ease. Neither would explain the oddity above if it's really happening, but another thing I was going to suggest was re-creating the rule just to see if it helps (maybe something got messed up internally before?), but if you're going to try that, you might as well make sure it really does what you want.
Motion active Sunset -30 works well that was what I was trying to explain in my first post whereas it continues beyond Sunrise +15 which is not what I expect.
Instead of "between Sunset-30 and Sunrise+15" try "NOT(between Sunrise+15 and Sunset-30)". In the later version, Sunset and Sunrise are on the same day. No guarantees that this will solve your issue, but it is something to try.
Have you looked in System Events -> Location Events and looked to see if you have Sunrise and Sunset times ocurring at the correct time.
Use the far right column.
No, not unless you want something to happen at those exact times. Your existing rule will run the actions whenever there is motion, which is probably all you want--just wanted to make sure since you did say that time was "trigger" (assuming you just meant "condition"). You can have multiple triggers (or none if you know what your other options are), but again, I don't think you need to here.
I strongly recommend reading the Rule 4.0 docs before diving in. (I can see nobody has clicked that link yet. The videos are fine but won't teach you everything you need, unfortunately.) As I mentioned, there are a few problems with your rule as a substitute for Motion Lighting. The motion lighting example the docs avoids this problem and will get you pretty close to what you want, but you'll have to add in your time conditions somehow. How/where you add it will depend on whether you want to restrict both the "on" and "off" actions or just the "on" action, among other things. There are also multiple other considerations you can make and several ways you could use or modify the examples (of which the above is only one) to suit your exact need.
That being said, I'd probably stick to Motion Lighting for this: it's a smaller app and will likely run faster (probably not much but a few hundred milliseconds, maybe--still, any amount of speed is great for indoor lighting automations, I think). Even for your example, Simple Lighting (soon to be renamed Simple Automation Rules) could handle things if you want to restrict both "off" and "on" actions in one rule (or make two, one for each, with whatever restrictions you do or don't want). But none will work if your sunrise and sunset times don't seem to be working correctly, which others' advice above may help you figure out. And there's certainly nothing wrong with learning RM, just wanted to point out that there are easier ways to do this.
Just to be clear about the problem: what "continues" beyond sunrise+15? The only thing that you should see happen if it's later than sunrise+15 (but before sunset-30) is that the "T" you currently see next to "Time between sunset-30 and sunrise+15 minutes" will change to an "F" (assuming you either reload the page or didn't already have it open--again, it doesn't dynamically update). Your screenshot above is definitely correct in this regard given the current time in your time zone, but I know you said this is the time you weren't having problems with, so I guess that's not terribly revealing.
I did a test for 2 days and I think there is something seriously wrong with either the rule, or location.
I took screenshots of the rule page (reloaded and refreshed) at 3 different times and it is showing completely wrong results of Sunrise and Sunset.
At 12:03AM, the 2nd rule shows FALSE (9PM to Sunrise which is incorrect) as it was showing correctly at 11:59AM
At 10:15AM, every other rule shows TRUE which is incorrect whereas (9PM to Sunrise shows FALSE which is correct)
Seems to be a bug in the way sunset and sunrise works or something wrong in my location or Rule setup. Its driving me crazy.
Edit: At 11:23am, I visited the Systems Events, Logs and Locations and modes page (did not save anything) and everything the rule looks great... VERY WIERD!!!
I notice that you have a NOT clause in your test rules. If you are trying to follow my advice from above, you need to swap the endpoints of the range (i.e. NOT(between Sunrise and Sunset)).
Here is a way to determine whether the problem is actually the time that Hubitat thinks sunrise and sunset occur. You can create two global variables of type Time. Then, you can have a rule that runs once a day to update these variables, like:
After the rule runs, you can see what time Hubitat thinks the sun sets and rises. (I set up a connector for these variables so I could display them on a dashboard just because I like to know when sunset and sunrise are.) Once you know whether Hubitat has the wrong sunrise time, that can direct your further debugging efforts.
Actually, checking what time Hubitat thinks that the sun rises and sets is simpler than what I described above. Just look at the System Events. sunriseTime and sunsetTime show up there.
The fact that the sunrise time is missing some days does seem odd.
The entry in the value field is in Zulu time whereas the entry in the date field is in local time. Also, it appears that the entry in the value field appears to be the next sunrise or sunset.
Thanks reid.a.baldwin for the analysis!
I am not sure what should I do next.
I followed all advice provided by you and @bertabcd1234 but still no success.
Thanks everyone for providing your help!
After a lot of sleepless nights, I finally figured out the problem. I had also connected my Samsung Smartthings as a remote hub and it was causing this interference. I deleted the hub and remote instance and also removed the link in Smartthings IDE account and the problem disappeared.
The sunset and sunrise with offsets works perfectly fine.
The videos are fine but won't teach you everything you need, unfortunately.) As I mentioned, there are a few problems with your rule as a substitute for Motion Lighting. The 
