Repository: oppia/oppia

Issue:
[BUG]: UTC timestamp is not calculated in the server correctly
### Describe the bug

We use `get_current_time_in_millisecs()` to calculate utc timestamp in msecs. The function might be incorrect. See the attached image. Old is the current function, new is the proposed change. On the right is a utc timestamp clock on the internet.

This is because `utcnow` returns the datetime in utc but without any timezone information. When it is converted to a timestamp, python's `datetime` library assumes that this object without any timezone information is in the local timezone of the server and computes the timezone accordingly. If you notice in the image above, the difference between the function and the correct timestamp is 19,800,000 milliseconds which is equal to 5.5 hours (time from my local machine).


### URL of the page where the issue is observed.

N/A

### Steps To Reproduce

N/A

### Expected Behavior

Expect the function to return the utc timestamp correctly.

### Screenshots/Videos

<img width="1728" alt="Screenshot 2023-08-15 at 8 18 41 AM" src="https://github.com/oppia/oppia/assets/31477127/11e0ac13-1d3f-4a85-bb1e-3e95c397d012">


### What device are you using?

Desktop

### Operating System

Windows

### What browsers are you seeing the problem on?

Other

### Browser version

N/A

### Additional context

_No response_

### Tips for developers

Before tackling the bug, please use `git bisect` (see https://git-scm.com/docs/git-bisect) to investigate which PR caused it (you only need to go back as far as commit https://github.com/oppia/oppia/commits/9a334e9). If you find the PR, leave a comment on this issue pointing to it, or just say that it happened before commit 9a334e9 if you could reproduce it there. This will help us fix the issue by reverting the faulty PR.

Also, if this is your first issue, please make sure to follow https://github.com/oppia/oppia/wiki/Contributing-code-to-Oppia#choosing-a-good-first-issue and https://github.com/oppia/oppia/wiki/Contributing-code-to-Oppia#setting-things-up before claiming it. Thanks!



Discussion:
Changing this is easy but I was wondering if it might cause issues with any of the previous timestamps stored in the database.

cc @seanlip 
Thanks @kapilag96 -- great catch! I took a look at all usages of get_current_time_in_millisecs() and I think it's fine to make this change. Some of our historical dates will be a few hours off (probably 7-8 since the server is in Pacific time) but for the current use cases I think that's OK.

Resolving patch:
diff --git a/core/utils.py b/core/utils.py
--- a/core/utils.py
+++ b/core/utils.py
@@ -619,8 +619,7 @@ def get_time_in_millisecs(datetime_obj: datetime.datetime) -> float:
     Returns:
         float. The time in milliseconds since the Epoch.
     """
-    msecs = time.mktime(datetime_obj.timetuple()) * 1000.0
-    return msecs + (datetime_obj.microsecond / 1000.0)
+    return datetime_obj.timestamp() * 1000.0
 
 
 def convert_millisecs_time_to_datetime_object(
@@ -673,7 +672,9 @@ def get_current_time_in_millisecs() -> float:
     Returns:
         float. The time in milliseconds since the Epoch.
     """
-    return get_time_in_millisecs(datetime.datetime.utcnow())
+    return get_time_in_millisecs(
+        datetime.datetime.now(datetime.timezone.utc)
+    )
 
 
 def get_human_readable_time_string(time_msec: float) -> str:


Test patch: