can someone in ontario with computer science field answer this please

I'm not sure why you'd specific Ontario. Computer science varies a little bit with time but very little with geography, particularly between Ontario and the US.

In general, you'll start your schooling with the typical STEM classes. In Computer Science you'll likely begin with a general-purpose computer language of some kind. This varies, and you might start with some elementary language to teach you the basic concept of programming. You may graduate to other languages. In my case I went from BASIC at the time to assembly. Why? Because assembly showed us how the guts of the machine actually worked. Since I was studying CS rather than Computer Technology, they assumed we would spend a lot of time going in depth to how machines worked rather than just using them as tools. You could easily compress this into some single "survey" course. You might eventually use a "survey of languages" course, which is a pretty interesting way of seeing that there are a LOT of different ways to program and lots of different architectures of machines.

Your math will include the advanced math to integral calculus. Finite mathematics will come in handy. Possibly a digital logic course. Operating systems. Computational architecture. Data structures and algorithms. All to give you an overview of computer science and related topics.

A typical day for a computer scientist at the start of a project would be starting meetings to discuss the problem, the project to solve it, how the team would approach it. We'd discuss schedule and milestones. In my case, as a Systems Engineer at the time, we discussed the business need, customer input. We might arrange various teams to attack parts of the project. From then on, we might have weekly meetings to discuss status, progress, achievements, problems. These are useful many times to share problems with other team members who might suggest fixes or work-arounds.

As a Systems Engineer, I was responsible for architecture and overall design approaches and putting sets of "requirements" or various things we promised the product would have to do. I'd analyze customer needs, market needs, etc. .

When I was a developer, I'd spend a large amount of my time implementing some design or other in code. The code would usually be part of a larger project, and it would be submitted to some larger repository. Using "Change Management Software", we'd insert what we'd written into the larger project's code.

Our code would be "unit tested" -- that is, we'd take our small piece of the project and devise ways to verify that it operated correctly, but off-line from the rest of the project. After we were satisfied with at least that particular version, that's when we'd submit our piece to the larger project.

Eventually we'd go to some sort of test bed. In our case, it was a switching laboratory, and we'd test larger and larger portions of the project until we had all of it. This is called "Integration Testing".

In those rare instances where your code was the entire project, such as a tool or application you were providing by yourself, you'd eventually complete your own testing to your satisfaction. You'd normally hand off the piece you thought was complete and let folks who were solely responsible for testing your product and verifying that each of those "requirements" you promised the code would meet were actually being provided to the satisfaction, hopefully, of the final customer.

After the project code was deemed "complete" and the testing group had verified the quality, stability, functionality, etc. of the product, it was time for "acceptance testing". This is when the customer (who could be an external customer or even just another department or team member) ran their own set of tests. If they were satisfied, they would "accept" it -- hence the name for these tests. If not, they'd record their complaint (a "bug" report), similar to what the testing group had done before, and you (or someone) would be responsible for putting in a fix and sending it for further testing.

This is a very general overview of what the software engineer-type of Computer Scientist does. There are variations, but this is rather common. I'd say the most fun part of this process is first, proposing a solution. After that, building your first prototype of a project. Quite a kick.