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
Generate and work with holidays in Python

python-holidays A fast, efficient Python library for generating country, province and state specific sets of holidays on the fly. It aims to make dete

Maurizio Montel 881 Dec 29, 2022
Useful extensions to the standard Python datetime features

dateutil - powerful extensions to datetime The dateutil module provides powerful extensions to the standard datetime module, available in Python. Inst

2k Dec 29, 2022
Python datetimes made easy

Pendulum Python datetimes made easy. Supports Python 2.7 and 3.4+. import pendulum now_in_paris = pendulum.now('Europe/Paris') now_in_par

Sébastien Eustace 5.3k Jan 06, 2023
Croniter provides iteration for the datetime object with a cron like format

Introduction Contents Introduction Travis badge Usage About DST About second repeats Testing if a date matches a crontab Gaps between date matches Ite

kiorky 152 Dec 30, 2022
Better dates & times for Python

Arrow: Better dates & times for Python Arrow is a Python library that offers a sensible and human-friendly approach to creating, manipulating, formatt

Arrow 8.2k Jan 05, 2023
🏹 Better dates & times for Python

Arrow: Better dates & times for Python Arrow is a Python library that offers a sensible and human-friendly approach to creating, manipulating, formatt

Arrow 8.2k Jan 09, 2023
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 08, 2023
Datetimes for Humans™

Maya: Datetimes for Humans™ Datetimes are very frustrating to work with in Python, especially when dealing with different locales on different systems

Timo Furrer 3.4k Dec 28, 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

118 Dec 20, 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 02, 2022
E-Ink Magic Calendar that automatically syncs to Google Calendar and runs off a battery powered Raspberry Pi Zero

E-Ink Magic Calendar that automatically syncs to Google Calendar and runs off a battery powered Raspberry Pi Zero

2.8k Jan 06, 2023
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 06, 2023
A simple in-process python scheduler library, designed to be integrated seamlessly with the `datetime` standard library.

scheduler A simple in-process python scheduler library, designed to be integrated seamlessly with the datetime standard library. Due to the support of

30 Dec 30, 2022
A Python module that tries to figure out what your local timezone is

tzlocal This Python module returns a tzinfo object with the local timezone information under Unix and Windows. It requires either Python 3.9+ or the b

Lennart Regebro 159 Dec 16, 2022
A datetime parser in Python by Ari24-cb24 and NekoFantic

datetimeparser A datetime parser in Python by Ari24-cb24 and NekoFantic V 1.0 Erinnerung für den Parser Auf falsche Eingaben überprüfen Liste an Event

AriDevelopment 13 Dec 30, 2022
A simple digital clock made with the help of python

Digital-Clock ⏰ Description 📚 ✔️ A simple digital clock made with the help of python. The code is easy to understand and implement. With this reposit

Mohit 0 Dec 10, 2021
pytz Python historical timezone library and database

pytz Brings the IANA tz database into Python. This library allows accurate and cross platform timezone calculations. pytz contains generated code, and

Stub 236 Jan 03, 2023
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 09, 2022
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 01, 2023
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