The DST rule of Brazil was changing the time around midnight? That's one of the worst moments during the day to do this, and this article clearly shows.
I have a couple of questions though. If the deadline field is just a date, why was time included? If only the date was stored you wouldn't have a problem with DST when displaying the date.
If you do store the time, you should also display it (and the timezone) for more complete correctness. Displaying time obviously is a big problem around DST changes. (One of the many reasons DST should be abolished.) This doesn't fix the above mentioned problem though, as many people do not understand timezones and how DST affects them. For example, most people in Europe would say it was CET (+02:00) 2 months ago, even though it was actually CEST (+03:00).
This is application just for Brazil? Then why even use time zones. Because that opens a whole new set of issues. Just using local time makes a lot of things easier.
MSc in Computer Science and a Full-stack Software Engineer at Peerdustry based on São Paulo with a strong technical background to develop Web Applications and distributed systems.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The DST rule of Brazil was changing the time around midnight? That's one of the worst moments during the day to do this, and this article clearly shows.
I have a couple of questions though. If the deadline field is just a date, why was time included? If only the date was stored you wouldn't have a problem with DST when displaying the date.
If you do store the time, you should also display it (and the timezone) for more complete correctness. Displaying time obviously is a big problem around DST changes. (One of the many reasons DST should be abolished.) This doesn't fix the above mentioned problem though, as many people do not understand timezones and how DST affects them. For example, most people in Europe would say it was CET (+02:00) 2 months ago, even though it was actually CEST (+03:00).
This is application just for Brazil? Then why even use time zones. Because that opens a whole new set of issues. Just using local time makes a lot of things easier.
You don't even want to play around with dates and time at all, there are so many problems.
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.