Disallow `strftime` in a code base

Question

I want to make sure that no developer on our codebase can ever check in code that uses strftime. It's a super useful method, but since it can't be used on dates before 1900, it's a constant source of bugs that we only discover once code goes live.

I've thought of a few ways to make it so it can't be used:

1. Create an inspection in Intellij that throws an error when strftime is encountered.

   (This seems OK, but creating Intellij inspections is a big deal.)

2. Create a unittest that greps any changes that are currently in the code and makes sure strftime hasn't snuck back in again.

   (Seems hacky and adds a dependency for some git tool.)

3. Create a git hook of some kind that explodes when strftime appears in a commit.

   (Looked into this but git hooks must be manually symlinked which kind of defeats the point -- kind of.)

4. Subclass the datetime module with an implementation that raises a NotImplemented error if strftime is ever used.

   (But people could still import the regular datetime module.)

5. Just train myself and everybody else that it's the devil.

   (But this hasn't worked so far.)

I feel like this is probably something that has a standard way of being resolved. Any suggestions?

Answer 1

Here's a variant of (4). I'm not necessarily sure if it's the best way to accomplish this, but it will work. Put this in your top-level __init__.py, which runs before everything else:

import datetime

class datetime(datetime.datetime):
    # Override strftime, and make any other changes here

datetime.datetime = datetime

This will monkey-patch the built-in datetime.datetime implementation with your hacked version. It's important to realize this will also break any of your dependencies which may be using datetime.strftime(), so test before deploying.

EDIT: I'm not sure if this will work, but you may be able to abuse Python's warnings system into working around the dependency problem. Start by changing your implementation to this:

import warnings

class datetime(datetime.datetime):
    def strftime(self, *args, **kwargs):
        warnings.warn('strftime is deprecated', DeprecationWarning, stacklevel=2)
        return super(datetime, self).strftime(*args, **kwargs)

This will issue a deprecation warning whenever the function is called. Deprecation warnings are ignored by default, so this will not create false positives for Django. You can then install a warning filter like so:

warnings.filterwarnings('error', 'strftime is deprecated', DeprecationWarning,
                        r'your_package(\..+)?') # regex matching your package

In theory, this filter should only raise exceptions on code within your_package. In practice, I have not tested it, so it might not raise any exceptions whatsoever.

Answer 2

Introduce them to the wx.DateTime class from wxPython - once they have got used to it you would need a gun to get them to use strftime - it is a static class so can be used without the rest of the wx tool chain and you do not need a wx.App before using it.

Some features:

• Wide range: the range of supported dates goes from about 4714 B.C. to some 480 million years in the future.
• Precision: not using floating point calculations anywhere ensures that the date calculations don't suffer from rounding errors.
• Many features: not only all usual calculations with dates are supported, but also more exotic week and year day calculations, work day testing, standard astronomical functions, conversion to and from strings in either strict or free format.
• Efficiency: objects of wxDateTime are small (8 bytes) and working with them is fast
• DST aware in some timezones.

Answer 3

Another approach would be to use pylint to lint your code. Specifically, the basic_checker could be used to warn when forbidden functions are used (the default is for map, filter, etc).

You could tie this as a pre-commit hook in git to ensure that the offending function is not used.

Answer 4

Yet another approach is to del time.strftime in some startup code.

It will be able to check it in but it will always throw AttributeError on access.