No, this isn't the right way. In some sense, using a tree is a premature optimization over using a simple collection. You can always add a tree or other indexing data structure later.
In the absence of any further information you should use the simplest possible data structure: a simple collection. I'd recommend using a simple table as you'll find in SQL, with rows and columns: columns like start date/time, end date/time, event type, event name, etc...
As your knowledge of the domain expands, you'll be zeroing in on which columns and which tables to have. Using a tree will hamper your agility — your ability to change as your project scope grows — whereas using a collection will not (and at worst, a collection will hamper your performance, and that's fixable).
When starting out, initially focus on the what of the domain, rather the how. What columns, rather than how to organize (hierarchical) structure, how to insert, how to search. If you need some optimized data structure or index, that can be done later.
Calendars imply long-term persistence anyway, which also suggests tables (and a database of some sort). (With a database you can index your date columns for better performance if you find you need it.)
Eventually, you'll have a good understanding of the consuming application's query and command patterns, and its performance! Now you can consider caching, other data structures, etc...
On another note, a tree as you describe will be very cumbersome. (Another reason to start with a simple collection, and optimize something later.)
What if you have a two day meeting that goes from the 31st to the 1st?
Following your logic: Are you going to represent hours as children of days, minutes as children of hours, seconds as children of minutes, etc..?