Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #34566 > unrolled thread

strptime - dates formatted differently on different computers

Back to article view | Back to comp.lang.python

Contents

  strptime - dates formatted differently on different computers noydb <jenn.duerr@gmail.com> - 2012-12-10 13:18 -0800
    Re: strptime - dates formatted differently on different computers noydb <jenn.duerr@gmail.com> - 2012-12-10 13:22 -0800
    Re: strptime - dates formatted differently on different computers Dave Angel <d@davea.name> - 2012-12-10 16:36 -0500
      Re: strptime - dates formatted differently on different computers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-11 02:07 +0000
    Re: strptime - dates formatted differently on different computers Michael Torrie <torriem@gmail.com> - 2012-12-10 22:34 -0700
    Re: strptime - dates formatted differently on different computers Chris Angelico <rosuav@gmail.com> - 2012-12-11 19:08 +1100
    Re: strptime - dates formatted differently on different computers Michael Torrie <torriem@gmail.com> - 2012-12-11 01:23 -0700
    Re: strptime - dates formatted differently on different computers Michael Torrie <torriem@gmail.com> - 2012-12-11 01:25 -0700
    Re: strptime - dates formatted differently on different computers Chris Angelico <rosuav@gmail.com> - 2012-12-11 19:32 +1100
    Re: strptime - dates formatted differently on different computers Greg Donald <gdonald@gmail.com> - 2012-12-11 02:35 -0600
      Re: strptime - dates formatted differently on different computers noydb <jenn.duerr@gmail.com> - 2012-12-11 06:52 -0800
      Re: strptime - dates formatted differently on different computers noydb <jenn.duerr@gmail.com> - 2012-12-11 06:52 -0800
      Re: strptime - dates formatted differently on different computers Marc Christiansen <usenet@solar-empire.de> - 2012-12-11 21:18 +0100
        Re: strptime - dates formatted differently on different computers Greg Donald <gdonald@gmail.com> - 2012-12-11 23:28 -0600
      Re: strptime - dates formatted differently on different computers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-12 05:05 +0000
        Re: strptime - dates formatted differently on different computers Greg Donald <gdonald@gmail.com> - 2012-12-11 23:29 -0600

#34566 — strptime - dates formatted differently on different computers

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?

[toc] | [next] | [standalone]

#34569

NTFS partition
Windows 7
Python 2.7

[toc] | [prev] | [next] | [standalone]

#34570

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

[toc] | [prev] | [next] | [standalone]

#34593

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

[toc] | [prev] | [next] | [standalone]

#34596

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.

[toc] | [prev] | [next] | [standalone]

#34601

On Tue, Dec 11, 2012 at 4:34 PM, Michael Torrie <torriem@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#34603

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.

[toc] | [prev] | [next] | [standalone]

#34604

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

[toc] | [prev] | [next] | [standalone]

#34605

n Tue, Dec 11, 2012 at 7:25 PM, Michael Torrie <torriem@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#34606

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

[toc] | [prev] | [next] | [standalone]

#34622

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?

[toc] | [prev] | [next] | [standalone]

#34623

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?

[toc] | [prev] | [next] | [standalone]

#34641

Greg Donald <gdonald@gmail.com> 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.

Interesting. First thing I tried gave an error:
>>> import locale
>>> locale.setlocale(locale.LC_ALL, '')
'LC_CTYPE=de_DE.utf8;LC_NUMERIC=de_DE.utf8;LC_TIME=de_DE.utf8;LC_COLLATE=C;LC_MONETARY=de_DE.utf8;LC_MESSAGES=C;LC_PAPER=de_DE.utf8;LC_NAME=de_DE.utf8;LC_ADDRESS=de_DE.utf8;LC_TELEPHONE=de_DE.utf8;LC_MEASUREMENT=de_DE.utf8;LC_IDENTIFICATION=de_DE.utf8'
>>> from dateutil.parser import parse
>>> 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
>>> parse('1.2.2013') # ambiguous, I know
datetime.datetime(2013, 1, 2, 0, 0) # should be datetime.datetime(2013, 2, 1, 0, 0)

so it doesn't like long german dates and it misparses the numerical
form. And I even was so nice to set the locale :) (not that it succeeds
without…)
I admit I didn't read any documentation on it apart from help(parse)
which mentions a parserinfo argument, so one could probably give it a
hand at parsing.

The only thing this shows is that parsing dates is difficult.

Marc

[toc] | [prev] | [next] | [standalone]

#34683

On Tue, Dec 11, 2012 at 2:18 PM, Marc Christiansen
<usenet@solar-empire.de> 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

[toc] | [prev] | [next] | [standalone]

#34682

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

[toc] | [prev] | [next] | [standalone]

#34684

On Tue, Dec 11, 2012 at 11:05 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web