Validation in Blazor is supposed to be moved to the model - it works through data annotations. You can find more details on that in the following pages:
So, while validation is in the model, it is integrated in the UI/UX through validation messages and validation summary components. Our components also offer invalid state - that is a red border around the invalid input whose validation fails.
Whether there will be round-trip to the server depends on the architecture you have chosen - in a client side blazor app there will be no trip to the server, it all happens in the browser. In a server-side blazor scenario, a SignalR connection is always maintained between the client and server for DOM diffs and the logic runs on the server, so there will always be a round trip for validation, and that's inevitable. The upside is that it is much more lightweight than the common form POST queries.
At this point I recommend you follow this request for a time picker and see what it offers once it becomes available: https://feedback.telerik.com/blazor/1405781-date-time-and-date-time-picker. Once we ship it, I encourage you to take it for a spin and test the data annotation validation that the framework provides. If there is something you would like to see in it, I suggest you then open a separate concrete request. I am now closing this one because it is very generic and either duplicates the other request for a time picker, or goes beyond the scope of a component.
Can you provide an example of some other component that performs the tasks you request? It does not have to be in Blazor, any web tool would do to showcase the concept of syncing a browser date with a server date and with handling zones, so we can get a better understanding of what you are looking for.
We are planning to have a DateTimePicker to go with the DatePicker that is already available. Input validation, however, comes down to the application, model, and framework and not so much about the UI component. Even with daylight savings time, all hours from the day are still valid to be chosen, and it is up to the application to determine how to handle boundary cases.
Moreover, at the moment there are issues with localization/internationalization and formats that come from the Mono framework: https://github.com/mono/mono/issues/6368. There are already people trying to work around these limitations (for example, here, here, here). At the moment we leave processing and .ToString() operations to the framework, and what you see as date and number formats, comes from .NET (or, rather, its Mono counterpart). Thus, once Blazor supports localization of date strings, this should start working immediately on our components.