Thanks for commenting, Michiel.
I agree that timezones are tricky, but they may be important depending on your requirements, especially to display date/times for your users and for deadlines.
I agree that storing only the date is simpler since you only need to rely on the backend timezones. However, you need to consider the client's timezone to schedule jobs to expire the tasks. What if the system is being used by people in different locations/timezones?
An alternative approach is to receive the professor's timezone along with the date and make the backend set the time based on the received timezone.
Brazil is huge and has 4 different time zones. So, even if the application is just for Brazil, we still have to handle different time zones.
I did not know Brazil has 4 time zones, then you obviously cannot avoid it.
Guess I fell for one of the common errors when handling dates and times, assuming countries only have a single timezones.
Besides that, even when we had daylight savings this was not applied to all states.
The DST was applied only to the states in the south, so even though two cities are in the same timezone, during the DST period they could have different times.
Not sure if this kind of stuff occurs in other countries as well.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.