Ability to run migrations depends on timestamp length

[m6butterfly]

While figuring out how to handle database migrations with micrate, granite, and amber I seem to have found a rather problematic error. I didn't realize that there are two ways, micrate directly and amber generate, to create a new migration file and ended up trying both.

If I generate a migration via micrate scaffold directly I get file names like 20220906195432_test_table_1.sql. If I generate a migration via amber g scaffold instead I get file names like 20220907021800909_create_test_3.sql. Notice that the timestamp portion of the file name is 3 characters longer for the amber generated file.

I can't run micrate up or amber database migrate if I have files with timestamps of different lengths as above. I get the following error:

bin/micrate up 2022-09-07T01:57:46.906956Z INFO - micrate.cli: The following migrations haven't been applied but have a timestamp older then the current version: 2022-09-07T01:57:46.907072Z INFO - micrate.cli: 20220906195432_test_table_1.sql 2022-09-07T01:57:46.907073Z INFO - micrate.cli: Micrate will not run these migrations because they may have been written with an older database model in mind. You should probably check if they need to be updated and rename them so they are considered a newer version.

This error occurs even when there are several days between the amber generated file's timestamp (older file) and the micrate generated file's timestamp (newer file).

However, if I add 3 zeros to the end of the timestamp portion of the micrate filename, i.e. 20220906195432000_test_table_1.sql, the migrations proceed as expected.

Running migrations should not be dependent on timestamp length to this degree.