Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Year 2038 bug - in use of timestamp in mySQL tables #952

Closed
taniwallach opened this issue May 28, 2019 · 2 comments
Closed

Year 2038 bug - in use of timestamp in mySQL tables #952

taniwallach opened this issue May 28, 2019 · 2 comments

Comments

@taniwallach
Copy link
Member

mySQL's timestamp is apparently still a 32-bit integer, so apparently suffers from the year 2038 bug:

timestamp is used in

  1. the course_key table (I think for the expiration time of the login key "cookie"), and
  2. the course_past_answer table (I think as the timestamp when the answer was submitted).

We have some time, but eventually unless mySQL/MariaDB fix this issue, these columns will need to be changed.

Background:
@drgrice1
Copy link
Member

This issue as stated is not valid. The information linked to refers to the mysql timestamp data type and mysql methods for working with that data type. The timestamp data type is never used by webwork. The issue does not apply to a column in a database that has the name "timestamp" but is of type "INT" or "BIGINT" which the columns that are referred to are. Note that the "INT" type is 4 bytes and will have the year 2038 issue if it holds a value that represents a timestamp, but that only applies to the timestamp column in the past answers table. This would be very easy to fix.

drgrice1 added a commit to drgrice1/webwork2 that referenced this issue Dec 18, 2024
@drgrice1
Change the timestamp column in the past answer table to BIGINT.
fe46bce 
Currently this column is of `INT` type.  The `INT` type is a 4 bit
integer, and so a timestamp stored in this column that is after the year
2038 will not work.  A `BIGINT` is large enough for my lifetime at least
(and then another 292 billion years or so).

There is no need to update databases since the INT and BIGINT types are
compatible.  However, at some point you will need to make sure that the
type of the column in all courses is updated.  You can run the
`upgrade-database-to-utf8mb4.pl` script to do this. For example, running
`upgrade-database-to-utf8mb4.pl -c courseId` will update the past answer
table for the named course.

This fixes issue openwebwork#952.
@drgrice1 drgrice1 mentioned this issue Dec 18, 2024
Merged
drgrice1 added a commit to drgrice1/webwork2 that referenced this issue Dec 19, 2024
@drgrice1
Change the timestamp column in the past answer table to BIGINT.
a40c26a 
Currently this column is of `INT` type.  The `INT` type is a 4 bit
integer, and so a timestamp stored in this column that is after the year
2038 will not work.  A `BIGINT` is large enough for my lifetime at least
(and then another 292 billion years or so).

There is no need to update databases since the INT and BIGINT types are
compatible.  However, at some point you will need to make sure that the
type of the column in all courses is updated.  You can run the
`upgrade-database-to-utf8mb4.pl` script to do this. For example, running
`upgrade-database-to-utf8mb4.pl -c courseId` will update the past answer
table for the named course.

This fixes issue openwebwork#952.
@taniwallach
Copy link
Member Author

Sorry. You are certainly correct. I was still pretty new to WeBWorK back then, and messed up. Your #2648 will fix the one column where the 4 byte INT column will run into the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@taniwallach @drgrice1