History, Timezones and Daylight Saving Time

Question

This is a question about pset 7, finance. As I'm just starting with that exercise, I'm not allowed to look at older posts about pset7 or finance at the moment. So if you think this is a duplicate question, please do not refer to any question which contains any part of a solution to pset 7 or finance ...

---

In pset7, finance, we will have to display a history table.

As far as I can see, the environment doesn't have a local timezone set. (Which of course is quite reasonable, as the CS50 IDE is not supposed to know my location or timezone.)

Question 1: (this is about the front end)

• Are we supposed to show times converted to our local timezone?
• Or are we supposed to show times converted to the timezone from whereever (sp?) Harvard is located?
• Or are we supposed to show times converted to the timezone from whereever the stock exchange is located?
• Or are we allowed to show times in UTC?

---

Question 2: (this is about the back end)

• Are we supposed to take into account that DLST is about to end in a couple of weeks in some parts of the world? In other words: Should we convert every timestamp to UTC before storing it in our historic database table?
• Or are we allowed to use whatever time is available to us, and simply store it into our database table without converting to UTC?

---

Some background for question 2:

The first hour after the clock goes back from daylight saving time to normal time, local times are equal to the local times from exactly one hour earlier. For that reason, it is common practice to use UTC in stead of local time when logging transactions in a database.

Failing to convert to UTC would lead to a disturbed timeline in your history, if you happen to run part of your tests during that hour (or if your application will be running during that hour next year, or in 2 years, ...) ...

---

Edit: Although this question will be hidden for me, I will probablybe able to reach it whenever someone adds a comment or an answer, as I will be getting a notification.

Answer 1

All very good questions and observations. Kudos for thinking about them all. In the real world, this would be very critical.

However, this is an implementation of a stock trading website - a simulation. It will be sufficient to use the timestamps provided by the server itself. No corrections for time zones of any kind will be necessary. In fact, I don't know if check50 is capable of supporting any such enhancements. ;-)

But since you brought it up, the best practice standard is this: when timestamps are important, it is best to record timestamps in UTC without any conversions to DST or any particular time zone. This eliminates any confusion about when the timestamp was actually recorded. It also eliminates any issues with setting clocks forward in the spring or, more importantly, duplicating a timestamp when pushing clocks back in the fall. It also eliminates issues with countries changing their clocks at different dates, and any issues with countries south of the equator (with DST in the northern winter/southern summer) vs. those north of the equator.

If needed, the timestamp can be converted by user interface or other code to local timestamps as desired, thus retaining the exact time in the database.

If timestamps are not important, such as saving the time and date of a comment in a forum, then local server timestamps are usually fine. It then becomes the discretion of the owner/programmer to decide just how much effort to put into it vs. how important it is to you to correct everything to local time for the user, or to display the times in some other manner.

You know what to do! ;-)