DateDataParserinstance? I would like to change the 'DATE_ORDER' to 'MDY` if the language is English because I use it on European data and British order differs from the American one
(\d+) (päivän| vuosi|kuukausi|viikko|tunti|minuutti|sekuntti) päästä: kuluttua \1 \2
Great, now the tests look much nicer!
skip: [":n", "."] in the lang file (the first one accounts for the genetives that are sometimes used), but still getting errors from the nosetest:
- 1 january 2016 + 1. january 2016
for my assertion:
param('fi', "1. tammikuuta, 2016", "1 january 2016"),
The dot is directly connected to the number, i.e. there is no space between them. Would that cause this problem?
Hello everyone, I just experimented with
dateparser in a small cli application for more flexible and natural date parsing. I noticed that importing the module takes quite some time:
$ time python -c 'import dateparse': ~2.5 s on MacBook Air Mid 2012, ~1.3 on a Desktop with Intel i5 3470.
I'm wondering if anyone encounter similar times and if I'm missing something obvious which could improve the import time (e.g. configuration)?
datetime.datetime(8020, 2, 1, 1, 0)
Hi, I'm trying to reason through how to deal with timezone info in some dates I'm parsing with dateparser, and I could use a little help.
The dates look like this
'November 13, 2012 7:00 AM ET', and dateparser parses it to
datetime.datetime(2012, 11, 13, 7, 0, tzinfo=<StaticTzInfo 'ET'>). The issue is that, if I convert it to iso format, it seems that it's always getting a
-5:00 offset. That's fine for this date, but it's wrong if you change the month to May, where the offset should be
I do care about the fact that these are Eastern time (the main purpose is linking with financial market data; a big majority are ET), so I'd like to preserve that. However, I also need to move these dates around a bit (e.g., into a database), and I'm concerned about the conversions applying this static offset (instead of interpreting ET as EST or EDT depending on the date). Any advice or best practices?