New DateType for argparse (like FileType but for dates)

[petedmarsh]

BPO	23884
Nosy	@bitdancer
Files	argparse_datetype.patch: Patch for new argparse.DateType feature

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2015-04-08.10:52:05.008>
created_at = <Date 2015-04-07.17:29:13.822>
labels = ['type-feature', 'library']
title = 'New DateType for argparse (like FileType but for dates)'
updated_at = <Date 2015-04-08.10:52:05.007>
user = 'https://bugs.python.org/petedmarsh'

bugs.python.org fields:

activity = <Date 2015-04-08.10:52:05.007>
actor = 'petedmarsh'
assignee = 'none'
closed = True
closed_date = <Date 2015-04-08.10:52:05.008>
closer = 'petedmarsh'
components = ['Library (Lib)']
creation = <Date 2015-04-07.17:29:13.822>
creator = 'petedmarsh'
dependencies = []
files = ['38859']
hgrepos = []
issue_num = 23884
keywords = ['patch']
message_count = 5.0
messages = ['240220', '240233', '240235', '240241', '240259']
nosy_count = 4.0
nosy_names = ['bethard', 'r.david.murray', 'paul.j3', 'petedmarsh']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue23884'
versions = ['Python 3.5']

[petedmarsh]

Hello,

Reasonably frequently I find myself needing to pass a date as a command line argument to a Python script I've written. Currently, argparse does not have a built support for dates - this adds a new class to argparse (much like the existing FileType) that parses arguments to datetime.date instances.

Example:

      >>> parser = argparse.ArgumentParser()
      >>> parser.add_argument('--start', type=argparse.DateType('%d/%m/%Y))
      >>> parser.add_argument('end', type=argparse.DateType())
      >>> parser.parse_args(['--start', '01/02/2015', '2015-01-03'])
      Namespace(end=datetime.date(2015, 1, 3), start=datetime.date(2015, 1, 2))

I think this would be a useful addition to the standard library, a quick Google shows that many people roll their own version of this anyway.

Support for datetime.datetime and perhaps even datetime.timedeltas might be good too, but date/times get a bit more complicated (timezones in general and varying support for the '%z' format string which is required to default to an ISO8601 date time).

Cheers,

Pete

[paulj3]

It's a possible addition, but I don't have sense of the demand for it.

I wonder, what does the class offer that a function like this doesn't?

    def adate(date_string):
        return datetime.datetime.strptime(date_string,'%Y-%m-%d').date()

I'd be hesitant to add FileType if wasn't already present. It hasn't aged very well. We've had bug issues related to v3 binary files, and contexts. The main feature that FileType (beyond verifying that the file actually does exist) adds is the recognition of '-' as stdin/out.

By analogy I'm lukewarm about adding a DateType class.

[paulj3]

Examples of datetime types from Stackoverflow:

http://stackoverflow.com/questions/21437258/defining-python-argparse-arguments
The suggested answer (but not accepted) is 'type=lambda s: datetime.datetime.strptime(s, '%Y-%m-%d')'

another
http://stackoverflow.com/questions/12462074/python-argparse-create-timedelta-object-from-argument

which references
https://gist.github.com/jnothman/4057689
'timedeltatype.py: An argparse type factory that produces datetime.timedelta objects'

and
http://stackoverflow.com/questions/25470844/specify-format-for-input-arguments-argparse-python
with a type function

[bitdancer]

Yes, I think this is a case where it is better for the application to define exactly what it needs rather than try to define a general solution that won't satisfy everyone :)

FileType's purpose is actually, I think, to give you an *open* file. Which is also where a number of the problems came from :)

[petedmarsh]

The consensus seems to be that this is simple enough for people to implement themselves (if they need it) and it's probably not worth adding to argparse, so I've closed this :)