strptime - dates formatted differently on different computers

Discussion in 'Python' started by noydb, Dec 10, 2012.

  1. noydb

    noydb Guest

    Follow-on question to this earlier topic - https://groups.google.com/d/topic/comp.lang.python/wnUlPBBNah8/discussion

    Was curious to know if there was a way to handle different user computers with different operating system set date formats. 2/10/2006 vs 2-10-2006, for example. Not an issue for my current task, but was just curious how this could be handled?

    If in my code I am declaring the user entered date foramtted as
    x = datetime.datetime.strptime(user_entered_time , "%m/%d/%Y %I:%M:%S %p") # format for my computer

    but on another person's computer, their's is set as 2-10-2006 14:26:06, the code fails. Can this be accounted for?
    noydb, Dec 10, 2012
    #1
    1. Advertising

  2. noydb

    noydb Guest

    NTFS partition
    Windows 7
    Python 2.7
    noydb, Dec 10, 2012
    #2
    1. Advertising

  3. noydb

    Dave Angel Guest

    On 12/10/2012 04:18 PM, noydb wrote:
    > Follow-on question to this earlier topic - https://groups.google.com/d/topic/comp.lang.python/wnUlPBBNah8/discussion


    For those who avoid googlegroups with a passion, and/or don't have
    internet access, the subject of that thread is "date-time comparison,
    aware vs naive", on this same mailing list.

    > Was curious to know if there was a way to handle different user computers with different operating system set date formats. 2/10/2006 vs 2-10-2006, for example. Not an issue for my current task, but was just curious how this could be handled?
    >
    > If in my code I am declaring the user entered date foramtted as
    > x = datetime.datetime.strptime(user_entered_time , "%m/%d/%Y %I:%M:%S %p") # format for my computer
    >
    > but on another person's computer, their's is set as 2-10-2006 14:26:06, the code fails.


    You can save people a lot of time if you just think before posting.
    What do you define as failure? is your motherboard smoking, or is the
    final result off by a second?
    Please reread my last message on the previous thread. If you want us to
    give you code advice, show us what you're doing, don't just describe it
    in vague terms.

    > Can this be accounted for?


    When accepting input from a user, consider their environment. Perhaps
    they're in a different timezone than your program (or your native
    location), or use some other ordering for the date (for example, the
    Japanese sensibly put year first, then month, then day. Other regions
    have different conventions. If you can't detect the user environment,
    then you'd better tell them yours. For example,by prompting for day,
    month, and year separately.


    --

    DaveA
    Dave Angel, Dec 10, 2012
    #3
  4. On Mon, 10 Dec 2012 16:36:37 -0500, Dave Angel wrote:

    > When accepting input from a user, consider their environment. Perhaps
    > they're in a different timezone than your program (or your native
    > location), or use some other ordering for the date (for example, the
    > Japanese sensibly put year first, then month, then day. Other regions
    > have different conventions. If you can't detect the user environment,
    > then you'd better tell them yours. For example,by prompting for day,
    > month, and year separately.


    +1

    In a nutshell, you can't know ahead of time what the user will be using
    as a date format, or what their computer will be set to use as date
    format. Unless you control the operating system and can force a
    particular date format, you are at the OS's mercy.

    Having stated that the problem is hard, what's the solution? I expect
    that it will depend on the OS. Presumably under Windows there is some way
    of asking Windows "What is the current date format?". I defer to Windows
    users for that. On Linux, and probably Mac OS X, I think this is the
    right way to get the system's preferred date format:

    py> import locale
    py> locale.setlocale(locale.LC_ALL, '') # You MUST call this first.
    'en_AU.utf8'
    py> locale.nl_langinfo(locale.D_FMT)
    '%d/%m/%y'

    You can pass that string on to strptime:

    py> import time
    py> time.strptime("11/12/13", '%d/%m/%y')
    time.struct_time(tm_year=2013, tm_mon=12, tm_mday=11, tm_hour=0,
    tm_min=0, tm_sec=0, tm_wday=6, tm_yday=346, tm_isdst=-1)



    --
    Steven
    Steven D'Aprano, Dec 11, 2012
    #4
  5. On 12/10/2012 02:18 PM, noydb wrote:
    > Follow-on question to this earlier topic - https://groups.google.com/d/topic/comp.lang.python/wnUlPBBNah8/discussion
    >
    > Was curious to know if there was a way to handle different user computers with different operating system set date formats. 2/10/2006 vs 2-10-2006, for example. Not an issue for my current task, but was just curious how this could be handled?
    >
    > If in my code I am declaring the user entered date foramtted as
    > x = datetime.datetime.strptime(user_entered_time , "%m/%d/%Y %I:%M:%S %p") # format for my computer
    >
    > but on another person's computer, their's is set as 2-10-2006 14:26:06, the code fails. Can this be accounted for?


    I use a module I got from pypi called dateutil. It has a nice submodule
    called parser that can handle a variety of date formats with good
    accuracy. Not sure how it works, but it handles all the common American
    date formats I've thrown at it.
    Michael Torrie, Dec 11, 2012
    #5
  6. On Tue, Dec 11, 2012 at 4:34 PM, Michael Torrie <> wrote:
    > I use a module I got from pypi called dateutil. It has a nice submodule
    > called parser that can handle a variety of date formats with good
    > accuracy. Not sure how it works, but it handles all the common American
    > date formats I've thrown at it.


    That sort of statement will get you either amusement or ire, depending
    on the respondent. From me, amusement, because there are enough
    "common American date formats" for you to feel you've done a thorough
    test.

    There are a LOT more date formats than those used in the USA. The most
    obvious trio is American MDY, European DMY, Japanese YMD, but there
    are plenty more to deal with. Have fun.

    ChrisA
    Chris Angelico, Dec 11, 2012
    #6
  7. On 12/11/2012 01:08 AM, Chris Angelico wrote:
    > There are a LOT more date formats than those used in the USA. The most
    > obvious trio is American MDY, European DMY, Japanese YMD, but there
    > are plenty more to deal with. Have fun.


    For the record I didn't write the module, so I don't care whether or not
    I have fun or not. The module is simply there, and I've found it quite
    useful for parsing free-form dates as arguments passed to my program.
    While what you say is correct--and the parser can be given hints about
    what order to expect numeric dates--if you read the OP's question, he
    really is mainly looking for a flexible date parser that can handle /
    instead of - as a separator. And going by his example, the order is the
    same, so if he can parse one he can parse the other. This is exactly
    the kind of thing the dateutil.parser module works for. That's why I
    suggested it. Sure he needs to always be aware of the order, but I have
    to assume that since his strptime had a specific order, he has a reason
    for assuming that order. If he wasn't he is now, of course.
    Michael Torrie, Dec 11, 2012
    #7
  8. On 12/11/2012 01:08 AM, Chris Angelico wrote:
    > That sort of statement will get you either amusement or ire, depending
    > on the respondent. From me, amusement, because there are enough
    > "common American date formats" for you to feel you've done a thorough
    > test.


    Also what I meant was common "english language" formats. Such as:

    1 Apr 2013
    April 1, 2013
    Apr 1
    Apr 2013
    1st of April, 2013
    April of 2013
    5pm on August 3

    http://labix.org/python-dateutil#head-a23e8ae0a661d77b89dfb3476f85b26f0b30349c
    Michael Torrie, Dec 11, 2012
    #8
  9. n Tue, Dec 11, 2012 at 7:25 PM, Michael Torrie <> wrote:
    > On 12/11/2012 01:08 AM, Chris Angelico wrote:
    >> That sort of statement will get you either amusement or ire, depending
    >> on the respondent. From me, amusement, because there are enough
    >> "common American date formats" for you to feel you've done a thorough
    >> test.

    >
    > Also what I meant was common "english language" formats. Such as:
    >
    > 1 Apr 2013
    > April 1, 2013
    > Apr 1
    > Apr 2013
    > 1st of April, 2013
    > April of 2013
    > 5pm on August 3


    Ah! Okay. So, more general than just "different delimiters and such
    that you'd find in the USA". Still, it did come across as rather
    amusing, worded the way you had it.

    ChrisA
    Chris Angelico, Dec 11, 2012
    #9
  10. noydb

    Greg Donald Guest

    On Mon, Dec 10, 2012 at 10:34:31PM -0700, Michael Torrie wrote:
    > I use a module I got from pypi called dateutil. It has a nice submodule
    > called parser that can handle a variety of date formats with good
    > accuracy. Not sure how it works, but it handles all the common American
    > date formats I've thrown at it.


    from dateutil.parser import parse
    dt = parse( whatever )

    I've throw all kind of date and timestamps at it.. have yet to see anything it won't parse.


    --
    Greg Donald
    Greg Donald, Dec 11, 2012
    #10
  11. noydb

    noydb Guest

    On Tuesday, December 11, 2012 3:35:29 AM UTC-5, Greg Donald wrote:
    > On Mon, Dec 10, 2012 at 10:34:31PM -0700, Michael Torrie wrote:
    >
    > > I use a module I got from pypi called dateutil. It has a nice submodule

    >
    > > called parser that can handle a variety of date formats with good

    >
    > > accuracy. Not sure how it works, but it handles all the common American

    >
    > > date formats I've thrown at it.

    >
    >
    >
    > from dateutil.parser import parse
    >
    > dt = parse( whatever )
    >
    >
    >
    > I've throw all kind of date and timestamps at it.. have yet to see anything it won't parse.
    >
    >
    >
    >
    >
    > --
    >
    > Greg Donald



    Thanks - I tried this (dateutil.parser import parsed...), and it works. I'm skeptical of it working for any crazy date string thrown at it, but for my purposes it should suffice -- and my purposes for now was purely just curiousity on how to handle if it became necessary.

    I tried figuring out Steve D'Aprano's solution above on my system (windows 7, python 2.7) - no luck. Sorry, I am a newbie, so I'm a bit lost on this --- my locale module doesnt offer a nl_langinfo function -- why would this be?
    noydb, Dec 11, 2012
    #11
  12. noydb

    noydb Guest

    On Tuesday, December 11, 2012 3:35:29 AM UTC-5, Greg Donald wrote:
    > On Mon, Dec 10, 2012 at 10:34:31PM -0700, Michael Torrie wrote:
    >
    > > I use a module I got from pypi called dateutil. It has a nice submodule

    >
    > > called parser that can handle a variety of date formats with good

    >
    > > accuracy. Not sure how it works, but it handles all the common American

    >
    > > date formats I've thrown at it.

    >
    >
    >
    > from dateutil.parser import parse
    >
    > dt = parse( whatever )
    >
    >
    >
    > I've throw all kind of date and timestamps at it.. have yet to see anything it won't parse.
    >
    >
    >
    >
    >
    > --
    >
    > Greg Donald



    Thanks - I tried this (dateutil.parser import parsed...), and it works. I'm skeptical of it working for any crazy date string thrown at it, but for my purposes it should suffice -- and my purposes for now was purely just curiousity on how to handle if it became necessary.

    I tried figuring out Steve D'Aprano's solution above on my system (windows 7, python 2.7) - no luck. Sorry, I am a newbie, so I'm a bit lost on this --- my locale module doesnt offer a nl_langinfo function -- why would this be?
    noydb, Dec 11, 2012
    #12
  13. On Tue, 11 Dec 2012 02:35:29 -0600, Greg Donald wrote:

    > On Mon, Dec 10, 2012 at 10:34:31PM -0700, Michael Torrie wrote:
    >> I use a module I got from pypi called dateutil. It has a nice
    >> submodule called parser that can handle a variety of date formats with
    >> good accuracy. Not sure how it works, but it handles all the common
    >> American date formats I've thrown at it.

    >
    > from dateutil.parser import parse
    > dt = parse( whatever )
    >
    > I've throw all kind of date and timestamps at it.. have yet to see
    > anything it won't parse.


    The question is not "will it parse", but will it parse CORRECTLY?

    What will it parse 11/12/10 as, and how do you know that is the intended
    date?


    --
    Steven
    Steven D'Aprano, Dec 12, 2012
    #13
  14. noydb

    Greg Donald Guest

    On Tue, Dec 11, 2012 at 2:18 PM, Marc Christiansen
    <> wrote:
    >>>> parse('1. Januar 2013')

    > Traceback (most recent call last):
    > File "<stdin>", line 1, in <module>
    > File "/usr/lib64/python3.3/site-packages/dateutil/parser.py", line 720, in parse
    > return DEFAULTPARSER.parse(timestr, **kwargs)
    > File "/usr/lib64/python3.3/site-packages/dateutil/parser.py", line 310, in parse
    > raise ValueError("unknown string format")
    > ValueError: unknown string format


    A parserinfo class can be passed to parse() for unknown locale strings.

    >>>> parse('1.2.2013') # ambiguous, I know

    > datetime.datetime(2013, 1, 2, 0, 0) # should be datetime.datetime(2013, 2, 1, 0, 0)


    In [2]: parse('1.2.2013', dayfirst=True)
    Out[2]: datetime.datetime(2013, 2, 1, 0, 0)



    --
    Greg Donald
    Greg Donald, Dec 12, 2012
    #14
  15. noydb

    Greg Donald Guest

    On Tue, Dec 11, 2012 at 11:05 PM, Steven D'Aprano
    <> wrote:
    > The question is not "will it parse", but will it parse CORRECTLY?
    >
    > What will it parse 11/12/10 as, and how do you know that is the intended
    > date?


    If it were me I'd look at more of the source dates I was tasked with
    parsing and dial it in using the appropriate dayfirst, yearfirst, etc.
    options.



    --
    Greg Donald
    Greg Donald, Dec 12, 2012
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Lozzi

    Dates dates dates dates... SQL and ASP.NET

    David Lozzi, Sep 29, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    845
    Rob Schieber
    Sep 30, 2005
  2. kongkolvyu
    Replies:
    4
    Views:
    478
    Old Wolf
    Jan 4, 2006
  3. Mark
    Replies:
    12
    Views:
    868
  4. PW

    Dates! Dates! Dates!

    PW, Aug 7, 2004, in forum: ASP General
    Replies:
    4
    Views:
    178
    Mark Schupp
    Aug 9, 2004
  5. Ryan
    Replies:
    2
    Views:
    123
Loading...

Share This Page