You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A clear and concise description of what the bug is:
the Y2K38 problem is the problem that will occur in 2038 for 32-bit systems.
This is because these systems keep time as the number of seconds since January 1, 1970 (the Unix epoch) and after 03:14:07 UTC on January 19, 2038 this number will overflow, which can lead to errors in time and date functions.
the bug is that PhpMyadmin still mentions that TimeStamp ends in 2038 instead of the year 2316 April 26
To Reproduce
Steps to reproduce the behavior:
Go to a table.
Click on structuur (structure)
Scroll down to starten (start)
Click on starten (start)
Click on arrow down next to INT
Scroll down to TIMESTAMP
Hover your mouse over TIMESTAMP
See error
"Een tijdstip, van 1970-01-01 00:00:01 UTC tot 2038-01-09 3:13:07 UTC, wordt opgeslagen als aantal seconden sinds het beginmoment
(1970-01-01 00:00:00 UTC)"
Expected behavior
See alt atribute:
"Een tijdstip, van 1970-01-01 00:00:01 UTC tot 2316-04-26 0:00:00 UTC, wordt opgeslagen als aantal seconden sinds het beginmoment
(1970-01-01 00:00:00 UTC)"
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain the bug.
Server configuration
Operating system: Windows 11 version 24H2 26100.1
Web server: Apache
Database version: MariaDB -> InnoDB
PHP version: 8.3
phpMyAdmin version: 5.2.1
Client configuration
Browser: Microsoft Edge 124.0.2478.51
Operating system: Windows 11 version 24H2 26100.1
Additional context
Add any other context about the bug here.
Why is my Program Files (x86) folder still full of 32-bit software and drivers?
The text was updated successfully, but these errors were encountered:
the TIMESTAMP data type can hold values between '1970-01-01 00:00:01' (UTC) and '2038-01-19 03:14:07' (UTC) (MariaDB 11.3 and earlier, 32-bit platforms ) or '2106-02-07 06:28:15 UTC' (from MariaDB 11.5, 64-bit platforms only).
This is not a bug, just the tooltip in Typs.php needs to be updated. E.g. to:
case 'TIMESTAMP':
return __(
'A timestamp, range is 1970-01-01 00:00:01 UTC to 2038-01-19 ' .
'03:14:07 UTC on 32-bit platforms (MariaDB 11.3 and earlier), ' .
'and up to 2106-02-07 06:28:15 UTC on 64-bit platforms (MariaDB 11.5 and later), ' .
'stored as the number of seconds since the epoch (1970-01-01 00:00:00 UTC)'
);
Describe the bug
A clear and concise description of what the bug is:
the Y2K38 problem is the problem that will occur in 2038 for 32-bit systems.
This is because these systems keep time as the number of seconds since January 1, 1970 (the Unix epoch) and after 03:14:07 UTC on January 19, 2038 this number will overflow, which can lead to errors in time and date functions.
the bug is that PhpMyadmin still mentions that TimeStamp ends in 2038 instead of the year 2316 April 26
To Reproduce
Steps to reproduce the behavior:
"Een tijdstip, van 1970-01-01 00:00:01 UTC tot 2038-01-09 3:13:07 UTC, wordt opgeslagen als aantal seconden sinds het beginmoment
(1970-01-01 00:00:00 UTC)"
Expected behavior
See alt atribute:
"Een tijdstip, van 1970-01-01 00:00:01 UTC tot 2316-04-26 0:00:00 UTC, wordt opgeslagen als aantal seconden sinds het beginmoment
(1970-01-01 00:00:00 UTC)"
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain the bug.
Server configuration
Client configuration
Additional context
Add any other context about the bug here.
Why is my Program Files (x86) folder still full of 32-bit software and drivers?
The text was updated successfully, but these errors were encountered: