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

[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:

• #213 (comment)
• #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.