Parse human-readable date/time strings

Overview

parsedatetime

Parse human-readable date/time strings.

Python 2.6 or greater is required for parsedatetime version 1.0 or greater.

While we still test with Python 2.6 we cannot guarantee that future changes will not break under 2.6

Downloads Travis CI Codecov Requirements Status Dependency Status

Installing

You can install parsedatetime using:

pip install parsedatetime

Running Tests

From the source directory:

make test

To run tests on several python versions, type make tox:

$ make tox
[... tox creates a virtualenv for every python version and runs tests inside of each]
py27: commands succeeded
py35: commands succeeded

This assumes that you have the versions you want to test under installed as part of your PyEnv environment:

pyenv install -s 2.6.9
pyenv install -s 2.7.11
pyenv install -s 3.5.2
pyenv install -s pypy-5.3
pyenv global 2.7.11 3.5.2 2.6.9 pypy-5.3

The tests depend on PyICU being installed using the pyicu-binary package which removes the source build step. PyICU depends on icu4c which on macOS requires homebrew:

brew install icu4c

The Makefile contains the macOS default values for them so you may need to tweak them.

Using parsedatetime

An example of how to use parsedatetime:

import parsedatetime

cal = parsedatetime.Calendar()

cal.parse("tomorrow")

To get it to a Python datetime object:

from datetime import datetime

time_struct, parse_status = cal.parse("tomorrow")

datetime(*time_struct[:6])

Parse datetime with timezone support (using pytz package):

import parsedatetime
import pytz
from pytz import timezone

cal = parsedatetime.Calendar()

datetime_obj, _ = cal.parseDT(datetimeString="tomorrow", tzinfo=timezone("US/Pacific"))

More detailed examples can be found in the examples directory.

Documentation

The generated documentation is included by default in the docs directory and can also be viewed online at https://bear.im/code/parsedatetime/docs/index.html

The docs can be generated by running:

make docs

Notes

The Calendar class has a member property named ptc which is created during the class init method to be an instance of parsedatetime_consts.CalendarConstants().

History

The code in parsedatetime has been implemented over the years in many different languages (C, Clipper, Delphi) as part of different custom/proprietary systems I've worked on. Sadly the previous code is not "open" in any sense of that word.

When I went to work for Open Source Applications Foundation and realized that the Chandler project could benefit from my experience with parsing of date/time text I decided to start from scratch and implement the code using Python and make it truly open.

After working on the initial concept and creating something that could be shown to the Chandler folks, the code has now evolved to its current state with the help of the Chandler folks, most especially Darshana.

Comments
  • fix for extra space before year causing bad parse

    fix for extra space before year causing bad parse

    A missing “+” for a whitespace match between month name and year is causing the year to not parse when an extra space is provided. E.g:

    >>> parsedatetime.Calendar().parse("August 2016")
    (time.struct_time(tm_year=2016, tm_mon=8, tm_mday=1, tm_hour=16, tm_min=41, tm_sec=35, tm_wday=1, tm_yday=236, tm_isdst=1), 1)
    >>> parsedatetime.Calendar().parse("August  2016")
    (time.struct_time(tm_year=2017, tm_mon=8, tm_mday=1, tm_hour=20, tm_min=16, tm_sec=0, tm_wday=1, tm_yday=236, tm_isdst=1), 3)
    

    This PR adds the missing “+” and a test for the scenario.


    This change is Reviewable

    opened by jonklein 17
  • Relative times containing years fail when computed from a leap day

    Relative times containing years fail when computed from a leap day

    When it is February 29 (like today!), parsedatetime.Calendar().parse("1 year") raises

    ValueError: day is out of range for month

    (It's trying to find February 29 in the following non-leap year, i.e., February 29, 2017.)

    I think this is unexpected behavior because people would expect to be able to specify relative time intervals in terms of years on any day. (For example, we had written code that always computes parse("1 year") relative to the present day, and it crashes when run today!)

    opened by schoen 16
  • testMonths fails

    testMonths fails

    $ python3 run_tests.py parsedatetime
    ..................F..............................
    ======================================================================
    FAIL: testMonths (parsedatetime.tests.TestUnits.test)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "./parsedatetime/tests/TestUnits.py", line 107, in testMonths
        self.assertTrue(_compareResults(self.cal.parse('1 month',  start), (target, 1)))
    AssertionError: False is not true
    
    ----------------------------------------------------------------------
    Ran 49 tests in 0.284s
    
    FAILED (failures=1)
    
    opened by zed 14
  • Strange issue with inconsistent behavior

    Strange issue with inconsistent behavior

    I do this:

    cal = parsedatetime.Calendar() datetime_obj, parse_status = cal.parseDT(datetimeString='thursday 6:00 am', tzinfo=timezone('Europe/Bucharest'))

    Resulting time I get is this:

    2016-06-30 03:00:00+00:00

    Here's the problem: I get this result when I run the query at 6:40am on June 30th.

    I think what's happening is because it's pre 9am (or some other time), it returns a time that has already passed instead of the following Thursday. eg. I was expecting this: 2016-07-07 03:00:00+00:00

    I don't see this in the docs, but will do more testing. Any input appreciated on why this happens. I'm expecting to say "Thursday 6:00am" and if the current time in given timezone is past 6am, return the following Thursday. I'm not seeing this behavior, though.

    Thank you -

    opened by zefoo 12
  • Thread-safe context & accuracy flag

    Thread-safe context & accuracy flag

    This is a refactor of current parsedatetime module. I removed all *Flag attributes from Calendar object and used thread-safe pdtContext to replace them. There are two huge methods in Calendar class, the parse() and _evalString(). They have been broke up into several small methods.

    Also, this pull request introduced a new system to record if certain datetime string contains year, month, week, day, hour, minute, second, halfday (for example, afternoon or midnight) or "now". With such ability, not only we can know if the string contains date/time, but also the accuracy of date/time it brings with.

    Method parse() and parseDT() are both added a new parameter "version". When version equals to 1 which is also the current default value, the methods' second return value is still the old "flag" style 0, 1, 2 or 3. But if version equals to 2, the methods will return a pdtContext object, which allows user to inspect the text deeper.

    opened by philiptzou 12
  • Fix/time before next offset

    Fix/time before next offset

    Fixes a scenario where there's a time before a modifier:

    >>> parsedatetime.Calendar().parse("1pm next Friday")
    (time.struct_time(tm_year=2016, tm_mon=9, tm_mday=2, tm_hour=4, tm_min=14, tm_sec=58, tm_wday=4, tm_yday=246, tm_isdst=-1), 3)
    

    This addresses the immediate issue by differentiating between the modifiers a little more - "next Friday" is not the same as "after Friday". There might be a deeper issue here of assuming that the first chunk is an offset (like "1 hour") when in fact, it could be a fully qualified time ("1 pm").


    This change is Reviewable

    opened by jonklein 11
  • "Unresolved attribute reference 'parse' for class 'object'... " in Pycharm IDE.

    Error: "Unresolved attribute reference 'parse' for class 'object'... " in Pycharm IDE.

    Version: parsedatetime-1.5

    Code to reproduce:

        from time import mktime
        import parsedatetime
        from datetime import datetime
    
        cal = parsedatetime.Calendar()
        time_struct, parse_status = cal.parse("tomorrow")
        datetime.fromtimestamp(mktime(time_struct))
    

    cal.parse -> cal is not being detects as class Calendar and instead as object, which of course has no definition parse. Not sure what exactly is causing this, but my guess would be due to Calendar() being embedded in the init.py file.

    I do not see this issue while importing any other python modules.

    bug 
    opened by sbonnick 10
  • AttributeError when running in the context of an HTTP request

    AttributeError when running in the context of an HTTP request

    I get random occurrences of the following error:

    AttributeError: 'thread._local' object has no attribute 'stack'
    

    I'm using the library in the process of an HTTP request and I think that might be interfering with the use of thread locals.

    bug 
    opened by alewisohn 10
  • Avoid parsing numbers within larger strings as if they were times

    Avoid parsing numbers within larger strings as if they were times

    For example, neither "$300" nor "300ml" are intended to be "3:00" but "300" and "300am" are fine. The time must be preceded by a space or hyphen (the hyphen is to allow 300-400 style ranges) or appear at the beginning of the string. The time (or time + meridian for AM/PM locales) must be followed by a word boundary.

    I opted for (\s|-|^) here since, especially considering currencies, many different symbols can precede a number and most will be treated as a word boundary. \b would not have fixed the $300 case.

    This is another one where I'm not sure if all cases are covered but the tests pass and it seems in general to be an improvement.

    I did not make any changes to evalRanges via RE_RTIMEHMS and RE_RTIMEHMS2 which look like they may still have word boundary issues. Both (\s?|^) (which due to the ? can match anything) and the lack of \b are a bit concerning. For completion since this version is somewhat focused on word boundary fixes we should probably fix those as well.

    Otherwise, I think this wraps up my work for this version. Will post a few ideas for the future but I'm not quite ready to get into some of the other parsedatetime-related issues that have come up in my project.

    opened by idpaterson 10
  • All dates in text

    All dates in text

    Hi, is it possible to recursively look for all dates in a text, for example extract one, eliminate this chunk of text, parse again for the next one, and so on? Any tips on how I should go for this using parsedatetime?

    question 
    opened by elyase 10
  • Fixes

    Fixes "next week" and similar modifier + unit pairs in nlp()

    Fixes #87 for which I had previously employed a workaround in my application to pre-process transform next month to in 1 month. I am submitting this as a pull request in the hope of some feedback or additional test cases. nlp() is somewhat under-tested; while I was able to find and fix a few resulting issues there are probably more cases to test. I would like to have a few eyes on this before I merge it in.

    Adjacency of modifier and unit

    It would not be acceptable to pull out standalone units as dates; simply mentioning the word "week" does not imply a specific date. Instead I required that these units be immediately preceded by a modifier, such that next week parses as a date but neither A week is a long time nor Next I will rest for a week parse as dates.

    Handling of number + unit pairs was not consistent

    One detail of the orginal nlp implementation stuck out to me. In the code that processes matches, there is a comment about proximity of terms and making logical combinations of phrases. Inside the loop, only phrases representing a date or time are parsed (excluding the third type, units). Only on the last iteration were units considered (if date or time or units: outside the loop vs if date or time: inside the loop).

    I added units within the loop, which could be a source of regression errors if there was a specific reason for that decision. I noticed that the test for nlp was passing only because the number + unit phrase in 5 minutes coincidentally appeared as the last matched phrase in the test. Move that sentence (And in 5 minutes I'm going to eat some food!) to the beginning of the test string and the test fails.

    @geoffreyfloyd, it was a few years ago but do you happen to remember if there was a reason the units were only checked outside the loop in 9401d0d1b6b400710af66fc9dc01d137288cdb3a?

    Postfix modifiers?

    In some locales such as Spanish the modifier follows the unit. For example, the English phrase next month could be any of the following in Spanish: el próximo mes, el mes que viene, el mes siguiente. I am unsure whether parsedatetime supports such postfix modifiers in parse(), but this commit will not support that format.

    opened by idpaterson 9
  • Bump certifi from 2021.10.8 to 2022.12.7

    Bump certifi from 2021.10.8 to 2022.12.7

    Bumps certifi from 2021.10.8 to 2022.12.7.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.


    This change is Reviewable

    dependencies 
    opened by dependabot[bot] 0
  • testNextMonth fails on February 29th

    testNextMonth fails on February 29th

    testNextMonth fails on February 29th - it returns a date two years later instead of one (e.g. 2022-02-28 instead of 2021-02-28 with a base date of 2020-02-29).

    This test reproduces the issue:

    def testNextMonthLeapYear(self):
        s = datetime.datetime(2020, 2, 29, self.hr, self.mn, self.sec)
        t = self.cal.inc(s, year=1)
        start = s.timetuple()
        target = t.timetuple()
    
        self.assertEqual(_tr(self.cal.parse('next February 28', start)),
                         _tr((target, pdtContext(pdtContext.ACU_MONTH | pdtContext.ACU_DAY))))
    

    Output

    AssertionError: Tuples differ: ((2022, 2, 28, 8, 21, 0, 0, 0, 0), pdtContext([47 chars]DAY)) != ((2021, 2, 28, 8, 21, 0, 0, 0, 0), pdtContext([47 chars]DAY))
    
    First differing element 0:
    (2022, 2, 28, 8, 21, 0, 0, 0, 0)
    (2021, 2, 28, 8, 21, 0, 0, 0, 0)
    
    - ((2022, 2, 28, 8, 21, 0, 0, 0, 0),
    ?        ---
    
    + ((2021, 2, 28, 8, 21, 0, 0, 0, 0),
    ?      +++
    
       pdtContext(accuracy=pdtContext.ACU_MONTH | pdtContext.ACU_DAY))
    

    Initially reported by @hroncok in https://bugzilla.redhat.com/show_bug.cgi?id=1808449

    opened by FelixSchwarz 0
  • recognize UTC timestamps

    recognize UTC timestamps

    this might seem weird, but I think those two should be different:

    >>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("next tuesday 18:00", tzinfo=pytz.timezone("CET"))[0])
    '2022-03-29 18:00:00+02:00'
    >>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("next tuesday 18:00 UTC", tzinfo=pytz.timezone("CET"))[0])
    '2022-03-29 18:00:00+02:00'
    >>> 
    

    ie. if I specifically pass a timezone in my date string, shouldn't parsedetime at least try to parse that timestamp?

    this also fails with more regular date formats:

    >>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("2022-03-03 18:00 UTC", tzinfo=pytz.timezone("CET"))[0])
    '2022-03-03 18:00:00+01:00'
    >>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("2022-03-03 18:00 UTC", tzinfo=pytz.timezone("EST"))[0])
    '2022-03-03 18:00:00-05:00'
    >>> 
    
    opened by anarcat 0
  • Support for preceding 'previous' modifiers

    Support for preceding 'previous' modifiers

    Hello,

    there is currently no support for preceding 'previous' modifiers used in some slavic languages, but afaik also German and Spanish... To explain what I mean: In Czech, to say eg 4 hours ago, we say před 4 hodinami, in German they say vor 4 Stunden etc. - the modifier precedes the time.

    Is there a simple way to implement a change like this at the moment? Thank you!

    opened by svehlada 0
  • Interpret

    Interpret "at" as an indicator for time

    It seems that parse("yesterday at 5") does not interpret 5 as time (i.e. hours). It would be nice if this was the case, as this seems a natural way of expressing time of day. From a brief look at the code, it looks like 5 on its own is too general to be interpreted as an indication of hours, however, I think that at could be used to pinpoint the meaning of the integer number.

    I understand that in locales that do not use the 24h clock, the simple 5 might be ambiguous (see #210), but at the moment this also does not work in locales that use the 24h clock. For example in the de_DE locale, gestern um 5 and gestern um 17 do not get parsed correctly and the default time of the locale is used.

    opened by giuliofoletto 0
Releases(v2.6)
  • v2.6(May 31, 2020)

    Push out v2.6 to gather up local fixes and updates

    PR #244 Polished README.rst PR #242 fix pyicu import to suppress warnings PR #239 Fixed missing comma in seconds strings

    Updated Pipfile and Makefile to: - update and move packages to the "dev" section - use Python 3.7 for pipenv - install tox-pipenv plugin to try and fix Tox (currently doesn't) - simplify tox.ini to try and fix Tox (didn't) - move ci makefile target to the circle config

    Source code(tar.gz)
    Source code(zip)
  • v2.5(Nov 19, 2019)

    v2.5 release

    PR #222 Fix to sanitize abbreviated months from icu PR #223 typo in RU locale in abbreviation for January PR #224 Fix lint errors for flake8 v3.5.0 PR #225 Add a constant for start hour PR #233 Add 'secs' and 'mins' into base units PR #226 Remove unused dependency on future

    Source code(tar.gz)
    Source code(zip)
  • v2.4(May 14, 2017)

  • v2.3(Mar 10, 2017)

  • v2.2(Jan 22, 2017)

    PR #180 -- Fixed override of the long time format for Australian locale Issue #178 -- fix date interpretation when day is also provided Issue #176 -- fix "some duration before noon/dinner/etc" Issue #175 -- update code example in readme Issue #174 -- fix "ass" being interpreted as a time Issue #169 -- On Python 2.6 Issue #147 -- examples/README refers to nonexistent (deleted?) file Issue #158 -- Switch to CircleCI from Travis Issue #161 -- Not able to parse javascript's ISO string format

    Source code(tar.gz)
    Source code(zip)
  • v2.1(Mar 2, 2016)

  • v2.0(Feb 29, 2016)

    Issue #145 cal.parse('2015-11-18') returns November 19th 2015 Issue #143 What is the second value returned by parse? Issue #141 Bad test case in TestComplexDateTimes Issue #123 update supporting files for v2.0 release Issue #124 Put locales into config-files (yaml) Issue #125 Remove extra files Issue #137 Year is parsed wrongly if the date is of format MMM DD, YYxx xx:SS bug Issue #136 Why I see 2016 instead of 2015? Issue #133 Bug: "2015-01-01" is parsed as the current date. Issue #126 "Unresolved attribute reference 'parse' for class 'object'... " in Pycharm IDE. bug Issue #120 the pdt_locales/en_AU.py file uses en_A for the localID instead of en_AU Issue #114 Dates in the format 'YYYY-MM-DD HH:MM' give the incorrect month and day Issue #112 Document getting a time from parsedatetime into a standard Python structure Issue #110 AttributeError when running in the context of an HTTP request Issue #109 YearParseStyle is ignored for dates in MM/DD style Issue #107 yyyy/mm/dd date format Issue #105 "this week" is not parsed Issue #103 get UTC times from parseDT - trouble with at 9:30 clock times being interpreted directly in UTC Issue #100 Fractional deltas result in incoherent results.

    PR #153 Fix/day of week offsets PR #146 Test failure: eom is correct, but expectation is wrong PR #142 Fixed all PyICU test failure PR #138 bug(date3): rely on comparison of hour and year strings but not strict char position PR #135 update manifest, clean up setup.py and move historical text files PR #130 Refactoring of pdt_locales PR #134 Uses codecov to generate coverage report PR #128 Master PR #127 Issue #126 - removed inheritance from object and removed return value… PR #118 ADD: improve russian locale PR #117 ADD: Russian Locale PR #116 Fix spelling of "separator". PR #115 Update README.rst PR #113 Add datetime example to readme. PR #111 Allowed real number appear in text like "5.5 days ago"

    Source code(tar.gz)
    Source code(zip)
  • v1.5(Jun 25, 2015)

    Issue #99 Which year is implied when given just a month and day? Next and last? question
    Issue #96 Word boundary issues for specials (on, at, in) in nlp
    Issue #94 inconsistent application of sourceTime in Calendar.parseDT
    Issue #87 nlp() doesn't recognize some "next ..." expressions
    Issue #84 Afternoon? bug
    Issue #82 'last week' and 'next week' are broken
    Issue #81 parse returns default time of 0900 with dates like 'next friday' despite passed struct_time bug
    Issue #78 Link for Travis in README is wrong
    Issue #72 Enable travis
    Issue #71 Calendar() class can not be initialized 1.4 (it's fine)
    Issue #66 Unexpected struct_time flag with Calendar.parse on HTML <a href> string
    Issue #65 NLP false positives
    Issue #63 Supporting multiple shortweekday abbreviations
    Issue #61 Short weekday abbreviations bug
    Issue #56 Parse words to numbers (thirteen => 13)
    Issue #54 testMonths fails
    
    Source code(tar.gz)
    Source code(zip)
  • v1.4(Jul 11, 2014)

    Updated setup.py for wheel compatibility renamed README.txt to README.rst renamed MANIFEST to MANIFEST.in cleaned up a lot of the doc and notes

    Commit 3fc165e701 mafagafo Now it works for Python 3.4.1 Commit d5883801e7 borgstrom Restore Python 2.6 compatibility

    Source code(tar.gz)
    Source code(zip)
  • v1.3(Jul 8, 2014)

    Issue #45 make a new release to really fix backwards compatibility Issue #43 Please tag version 1.3

    Commit 29c5c8961d devainandor fixed Python 3 compatibility in pdtLocale_icu Commit d7304f18f7 inean Fix support for 'now' when no modifiers are present Commit 26bfc91c28 sashaacker Added parseDT method. Commit 848deb47e2 rmecham Added support for dotted meridians. Commit c821e08ce2 ccho-sevenrooms corrected misspelling of 'thirteen'

    many changes - amazing how hard it is to keep this file up to date when using GitHub.

    Biggest change is the addition of the nlp() function by Geoffrey Floyd: nlp() function that utilizes parse() after making judgements about what datetime information belongs together. It makes logical groupings based on proximity and returns a parsed datetime for each matched grouping of datetime text, along with location info within the given inputString.

    Source code(tar.gz)
    Source code(zip)
Owner
Mike Taylor
Mike Taylor
Make Python datetime formatting human readable

Make Python datetime formatting human readable

James Timmins 0 Oct 3, 2021
PyTime is an easy-use Python module which aims to operate date/time/datetime by string.

PyTime PyTime is an easy-use Python module which aims to operate date/time/datetime by string. PyTime allows you using nonregular datetime string to g

Sinux 148 Dec 9, 2022
ISO 8601 date/time parser

ISO 8601 date/time parser This module implements ISO 8601 date, time and duration parsing. The implementation follows ISO8601:2004 standard, and imple

null 118 Dec 20, 2022
UNIX time from NTP or short UtfN is a simple CLI tool to set the time from an NTP-Server.

UNIX ⌚ from NTP UNIX time from NTP or short UtfN is a simple CLI tool to set the time from an NTP-Server. Sets time and date using the date command pr

Alexander 1 Jan 2, 2022
⌚️Internet Time reference and (eventually) converter site, for planning things with your internet friends who aren't (yet) obsessed with Internet Time 😉

Internet-Ti.me Internet Time reference and (eventually) converter site, for planning things with your internet friends who aren't (yet) obsessed with

Jessica Stokes 17 Nov 2, 2022
A Python 3 library for parsing human-written times and dates

Chronyk A small Python 3 library containing some handy tools for handling time, especially when it comes to interfacing with those pesky humans. Featu

Felix Wiegand 339 Dec 19, 2022
Delorean: Time Travel Made Easy

Delorean: Time Travel Made Easy Delorean is a library for clearing up the inconvenient truths that arise dealing with datetimes in Python. Understandi

Mahdi Yusuf 1.8k Dec 20, 2022
TimeTagger is a web-based time-tracking solution that can be run locally or on a server

TimeTagger is a web-based time-tracking solution that can be run locally or on a server. In the latter case, you'll want to add authentication, and also be aware of the license restrictions.

Almar Klein 626 Jan 6, 2023
darts is a Python library for easy manipulation and forecasting of time series.

A python library for easy manipulation and forecasting of time series.

Unit8 5.2k Jan 1, 2023
Cross Platform Application for Calculating Render Time

mdsanima-rt-go Cross Platform Application for Calculating Render Time. Testing This is a base application build on Windows Android and Linux. All buil

MDSANIMA DEV 2 Mar 29, 2022
This is a Python 3.10 port of mock, a library for manipulating human-readable message strings.

This is a Python 3.10 port of mock, a library for manipulating human-readable message strings.

Alexander Bartolomey 1 Dec 31, 2021
Scan the MRZ code of a passport and extract the firstname, lastname, passport number, nationality, date of birth, expiration date and personal numer.

PassportScanner Works with 2 and 3 line identity documents. What is this With PassportScanner you can use your camera to scan the MRZ code of a passpo

Edwin Vermeer 441 Dec 24, 2022
python parser for human readable dates

Python parser for human readable dates Key Features • How To Use • Installation • Common use cases • You may also like... • License Key Features Suppo

Scrapinghub 2.2k Jan 8, 2023
Transpiles some Python into human-readable Golang.

pytago Transpiles some Python into human-readable Golang. Try out the web demo Installation and usage There are two "officially" supported ways to use

Michael Phelps 318 Jan 3, 2023
Make Python datetime formatting human readable

Make Python datetime formatting human readable

James Timmins 0 Oct 3, 2021
Neogex is a human readable parser standard, being implemented in Python

Neogex (New Expressions) Parsing Standard Much like Regex, Neogex allows for string parsing and validation based on a set of requirements. Unlike Rege

Seamus Donnellan 1 Dec 17, 2021
The ability of computer software to identify words and phrases in spoken language and convert them to human-readable text

speech-recognition-py Speech recognition is the ability of computer software to identify words and phrases in spoken language and convert them to huma

Deepangshi 1 Apr 3, 2022
A human-readable PyTorch implementation of "Self-attention Does Not Need O(n^2) Memory"

memory_efficient_attention.pytorch A human-readable PyTorch implementation of "Self-attention Does Not Need O(n^2) Memory" (Rabe&Staats'21). def effic

Ryuichiro Hataya 7 Dec 26, 2022
This application is the basic of automated online-class-joiner(for YıldızEdu) within the right time. Gets the ZOOM link by scheduled date and time.

This application is the basic of automated online-class-joiner(for YıldızEdu) within the right time. Gets the ZOOM link by scheduled date and time.

215355 1 Dec 16, 2021
Python 3 module to print out long strings of text with intervals of time inbetween

Python-Fastprint Python 3 module to print out long strings of text with intervals of time inbetween Install: pip install fastprint Sync Usage: from fa

Kainoa Kanter 2 Jun 27, 2022