strptime - dates formatted differently on different computers

[noydb]

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]

NTFS partition
Windows 7
Python 2.7

 

[Dave Angel]

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.

 

[Steven D'Aprano]

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)

 

[Michael Torrie]

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.

 

[Chris Angelico]

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

 

[Michael Torrie]

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]

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

 

[Chris Angelico]

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

 

[Greg Donald]

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.

 

[noydb]

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.

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]

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.

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?

 

[Steven D'Aprano]

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?

 

[Greg Donald]

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.

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]

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.