Migrations that begin with the year 2024 fail during the 'up' migration process

[alazarbeyenenew2]

Describe the Bug
Migrations that begin with the year 2024 fail during the 'up' migration process.

Steps to Reproduce

1. run migration create
   migrate create -ext sql -dir internal/constant/query/schemas -tz "UTC"_sql_name
2. run migrate up
   3

Expected Behavior

`User
panic: suint(-2077783112) expects input >= 0

goroutine 54 [running]:
github.com/golang-migrate/migrate/v4.suint(...)
github.com/golang-migrate/migrate/v4/util.go:45
github.com/golang-migrate/migrate/v4.(*Migrate).readUp(0xd1e9d40, 0xffffffff, 0xffffffff, 0xd294340)
github.com/golang-migrate/migrate/v4/migrate.go:582 +0x6be
created by github.com/golang-migrate/migrate/v4.(*Migrate).Up in goroutine 1
github.com/golang-migrate/migrate/v4/migrate.go:283 +0xea
make: [Makefile:4: migrate-up] Error 2 (ignored)`

Migrate Version
e.g. v3.4.15, v3.4.17

Loaded Source Drivers
e.g. s3, github, go-bindata, gcs, file
Obtained by running: migrate -help

Loaded Database Drivers
e.g. postgresql

Stacktrace

`User
panic: suint(-2077783112) expects input >= 0

goroutine 54 [running]:
github.com/golang-migrate/migrate/v4.suint(...)
github.com/golang-migrate/migrate/v4/util.go:45
github.com/golang-migrate/migrate/v4.(*Migrate).readUp(0xd1e9d40, 0xffffffff, 0xffffffff, 0xd294340)
github.com/golang-migrate/migrate/v4/migrate.go:582 +0x6be
created by github.com/golang-migrate/migrate/v4.(*Migrate).Up in goroutine 1
github.com/golang-migrate/migrate/v4/migrate.go:283 +0xea
make: [Makefile:4: migrate-up] Error 2 (ignored)`

[edsonjuniordev]

I have the same problem

[alazarbeyenenew2]

I solved the problem by manually changing the year to 2023

[dhui]

suint(-2077783112) looks like an overflow. Are you on a 32-bit system?
See also:

• migrate up fails on negative int #213 (comment)
• Re-think migration version numbers #214

[edsonjuniordev]

I'm using a 64-bit system. And the problem started to occur in 2024.

[alazarbeyenenew2]

i am on 64-bit but this is this is started 2024 this is how i identify the problem then try to solve in my way

[oitan]

y2k never ended

[mateusfmello]

I'm having the same problem.

I believe the quickest solution to this would be to migrate away from timestamps and use the sequential option.

However, I see that it is a complex thing to do because in addition to having to change all the migration files, you also have to update the database.

Looking at the database I have, the schema_migrations table only has one version line, but it is a version code that does not exist in my migrations. I think it might be the time stamp of the last run, but I'm not sure and I don't see much point in it. In Doctrine, which I am more accustomed to using, as I am migrating from PHP to GoLang, it stores all executed migrations, that is, each migration after being executed becomes a row in the schema_migrations table.

If someone can guide me on how Migrate works with the schema_migrations table, I can write a script to facilitate the migration of the timestamp to 6-digit sequential order, which is the default for migrate create -seq.