Add epoch as an option for file_template

[ccrvlh]

Hi all, as we are not huge fans of big file names, we would rather use epoch as a way to have the migrations in chronological order. I made a small change (with docs and test) to allow the epoch to be used in the file_template. From what I could see, this shouldn't have many side effects. As this is my first PR around here, please let me know if there's anything that I should do differently.

Description

• Added epoch as an option to the file_template.
• Added a test to make sure the epoch is considered on the name
• Added a test to make sure the epoch formula is correct (one extra second increases epoch by 1)

Checklist

This pull request is:

• A documentation / typographical error fix
• A short code fix
• A new feature implementation
  • Fixes: Add epoch as an option for the file_template #1027

[zzzeek]

we can add this but let's use std library

[zzzeek]

I'd rather not hardcode this here. you can call create_date.timestamp():

>>> import time
>>> import datetime
>>> create_date = datetime.datetime.now()
>>> epoch_reference_date = datetime.datetime(1970, 1, 1)
>>> epoch = int((create_date - epoch_reference_date).total_seconds())
>>> epoch
1651522726
>>> create_date.timestamp()
1651537126.489675

[zzzeek]

I think the latter is using UTC which accounts for the discrepancy

[ccrvlh]

Sure, the reason I chose that path was because going with timestamp() would need a round(..., 0) and the conversion to int to avoid the decimals, but I guess it should work without problems.

Do you think this int(round(create_date.timestamp(), 0)) could work?

>>> import time
>>> import datetime
>>> create_date = datetime.datetime.now()
>>> epoch_reference_date = datetime.datetime(1970, 1, 1)
>>> epoch = int((create_date - epoch_reference_date).total_seconds())
>>> epoch
1651527473
>>> create_date.timestamp()
1651538273.443539
>>> int(round(create_date.timestamp(),0))
1651538273
>>> int(create_date.timestamp())
1651538273

Actually I think just the int conversion would be enough int(create_date.timestamp())

[zzzeek]

yeah just int it, i think that's fine

[ccrvlh]

great, just pushed the new version and fixes tests, everything seems to pass.
thanks a lot for the fast review @zzzeek

[CaselIT]

looks ok, but the test fail, could you take a look?

You find the failure in the action checks

[ccrvlh]

Sure, just found out it is because of the timezone, I'm GMT -3 and tests pass locally, so when running on GMT the epochs differ, I'll take a look on how to fix this.

[zzzeek]

Sure, just found out it is because of the timezone, I'm GMT -3 and tests pass locally, so when running on GMT the epochs differ, I'll take a look on how to fix this.

try to use all GMT for the source datetime objects that are created in the test.

[ccrvlh]

I think that adding the tzinfo (and adding the correct utc epoch) works: create_date = datetime.datetime(2012, 7, 25, 15, 8, 5, tzinfo=tz.gettz("UTC")) I'll test in a vagrant box in UTC to see make sure. Passes locally now with the right epoch.

[sqla-tester]

OK, this is sqla-tester setting up my work on behalf of CaselIT to try to get revision 27970cd of this pull request into gerrit so we can run tests and reviews and stuff

[sqla-tester]

New Gerrit review created for change 27970cd: https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/3823

[sqla-tester]

mike bayer (zzzeek) wrote:

thanks for the contribution!

View this in Gerrit at https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/3823

[sqla-tester]

Gerrit review https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/3823 has been merged. Congratulations! :)