Rename `fold` parameter of `datetime.datetime()` to `clock_forwarded` & change its data type from `int` to `bool`

I would very much prefer if the fold parameter of datetime.datetime() would be named clock_forwarded, and instead of accepting an int value of either a 0 or a 1 to rather accept a Boolean value of either False or True (where False should be the default).

That way, it’d be more readable:
datetime.datetime(..., clock_forwarded=False)
or
datetime.datetime(..., clock_forwarded=True)

Now compare that to datetime.datetime(..., fold=0).

(I, personally, had so much trouble discerning what that ghastly fold was there for, so I am proposing this change to increase readability. I can create a PR if you see any benefit in this.)

Such a change would break existing code, so it’s not likely we’ll make this change.

I understand, but the fold parameter name is so bad that it’s actually criptic. It’d be wise to do something about it. Also, it accepting either a 0 or a 1 screams for the Boolean type.

See pep-0495: Why “fold”? for why it is the way it is.

the attribute were changed from False/True to 0/1. The noun “fold” has correct connotations and easy mnemonic rules, but at the same time does not invite unbased assumptions.

3 Likes

I guess the best thing you can do about this is not to use local time in your applications, but instead work with UTC time values wherever you can.

You still keep the problem of what to do with local time values entered by users pointing to a folding period (ie. parsing local time), but there are other ways to work around this, e.g. ask the user to disambiguate the value (e.g. by requiring DST information), use external resources to disambiguate, raise an exception, etc.

2 Likes