timofurrer / maya

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. This library exists to make the simple things much easier, while admitting that time is an illusion (timezones doubly so).

Datetimes should be interacted with via an API written for humans.

Maya is mostly built around the headaches and use-cases around parsing datetime data from websites.

☤ Basic Usage of Maya

Behold, datetimes for humans!

>>> now = maya.now()
<MayaDT epoch=1481850660.9>

>>> tomorrow = maya.when('tomorrow')
<MayaDT epoch=1481919067.23>

>>> tomorrow.slang_date()
'tomorrow'

>>> tomorrow.slang_time()
'23 hours from now'

# Also: MayaDT.from_iso8601(...)
>>> tomorrow.iso8601()
'2017-02-10T22:17:01.445418Z'

# Also: MayaDT.from_rfc2822(...)
>>> tomorrow.rfc2822()
'Fri, 10 Feb 2017 22:17:01 GMT'

# Also: MayaDT.from_rfc3339(...)
>>> tomorrow.rfc3339()
'2017-02-10T22:17:01.44Z'

>>> tomorrow.datetime()
datetime.datetime(2016, 12, 16, 15, 11, 30, 263350, tzinfo=<UTC>)

# Automatically parse datetime strings and generate naive datetimes.
>>> scraped = '2016-12-16 18:23:45.423992+00:00'
>>> maya.parse(scraped).datetime(to_timezone='US/Eastern', naive=True)
datetime.datetime(2016, 12, 16, 13, 23, 45, 423992)

>>> rand_day = maya.when('2011-02-07', timezone='US/Eastern')
<MayaDT epoch=1297036800.0>

# Maya speaks Python.
>>> m = maya.MayaDT.from_datetime(datetime.utcnow())
>>> print(m)
Wed, 20 Sep 2017 17:24:32 GMT

>>> m = maya.MayaDT.from_struct(time.gmtime())
>>> print(m)
Wed, 20 Sep 2017 17:24:32 GMT

>>> m = maya.MayaDT(time.time())
>>> print(m)
Wed, 20 Sep 2017 17:24:32 GMT

>>> rand_day.day
7

>>> rand_day.add(days=10).day
17

# Always.
>>> rand_day.timezone
UTC

# Range of hours in a day:
>>> maya.intervals(start=maya.now(), end=maya.now().add(days=1), interval=60*60)
<generator object intervals at 0x105ba5820>

# snap modifiers
>>> dt = maya.when('Mon, 21 Feb 1994 21:21:42 GMT')
>>> dt.snap('@d+3h').rfc2822()
'Mon, 21 Feb 1994 03:00:00 GMT'

# snap modifiers within a timezone
>>> dt = maya.when('Mon, 21 Feb 1994 21:21:42 GMT')
>>> dt.snap_tz('+3h@d', 'Australia/Perth').rfc2822()
'Mon, 21 Feb 1994 16:00:00 GMT'

☤ Advanced Usage of Maya

In addition to timestamps, Maya also includes a wonderfully powerful MayaInterval class, which represents a range of time (e.g. an event). With this class, you can perform a multitude of advanced calendar calculations with finesse and ease.

For example:

>>> from maya import MayaInterval

# Create an event that is one hour long, starting now.
>>> event_start = maya.now()
>>> event_end = event_start.add(hours=1)

>>> event = MayaInterval(start=event_start, end=event_end)

From here, there are a number of methods available to you, which you can use to compare this event to another event.

☤ Why is this useful?

• All timezone algebra will behave identically on all machines, regardless of system locale.
• Complete symmetric import and export of both ISO 8601 and RFC 2822 datetime stamps.
• Fantastic parsing of both dates written for/by humans and machines (maya.when() vs maya.parse()).
• Support for human slang, both import and export (e.g. an hour ago).
• Datetimes can very easily be generated, with or without tzinfo attached.
• This library is based around epoch time, but dates before Jan 1 1970 are indeed supported, via negative integers.
• Maya never panics, and always carries a towel.

☤ What about Delorean, Arrow, & Pendulum?

All these projects complement each other, and are friends. Pendulum, for example, helps power Maya's parsing.

Arrow, for example, is a fantastic library, but isn't what I wanted in a datetime library. In many ways, it's better than Maya for certain things. In some ways, in my opinion, it's not.

I simply desire a sane API for datetimes that made sense to me for all the things I'd ever want to do—especially when dealing with timezone algebra. Arrow doesn't do all of the things I need (but it does a lot more!). Maya does do exactly what I need.

I think these projects complement each-other, personally. Maya is great for parsing websites, and dealing with calendar events!

☤ Installing Maya

Installation is easy, with:

$ pip install maya

How to Contribute

1. Check for open issues or open a fresh issue to start a discussion around a feature idea or a bug.
2. Fork the repository on GitHub to start making your changes to the master branch (or branch off of it).
3. Write a test which shows that the bug was fixed or that the feature works as expected.
4. Send a pull request and bug the maintainer until it gets merged and published. :)

maya's Issues

parsing for intervals

imho It would be a great feature if parsing of strings for timedeltas/periods were possible.

e.g.

maya.parse_interval('1d 10min')
maya.parse_interval('daily')
maya.parse_interval('weekly')
maya.parse_interval('biannually')
maya.parse_interval('every 2 days')

At least the first is possible with pandas.Timedelta.

No version 1 release

If you feel the API is stable, please release a version 1 so that we know that it can be depended upon. Sem versioning says major version zero allows API to be broken at any time.

Until there is a major version 1 release, I will not use this as a future release may break my software.

MayaInterval unable to initialize

Hi,

In my use case I try to initialise maya.MayaInterval and provide all required arguments but it fails with the following exception

In [36]: start = maya.now()
In [37]: end = start.subtract(days=100)
In [38]: delta = 3600 * 24
In [39]: interval = maya.MayaInterval(start=start, end=end, duration=delta)
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
/Users/sultan/.pyenv/versions/3.6.0/lib/python3.6/site-packages/maya/core.py in __init__(self, start, end, duration)
    298             ))
--> 299             assert not all((start, end, duration is not None))
    300         except AssertionError:

AssertionError: 

During handling of the above exception, another exception occurred:

ValueError                                Traceback (most recent call last)
<ipython-input-39-01c7b43fed32> in <module>()
----> 1 interval = maya.MayaInterval(start=start, end=end, duration=delta)

/Users/sultan/.pyenv/versions/3.6.0/lib/python3.6/site-packages/maya/core.py in __init__(self, start, end, duration)
    300         except AssertionError:
    301             raise ValueError(
--> 302                 'Exactly 2 of start, end, and duration must be specified')
    303 
    304         # Convert duration to timedelta if seconds were provided.

ValueError: Exactly 2 of start, end, and duration must be specified

Is the given assertion assert not all((start, end, duration is not None)) is incorrect, because it always raises AssertionError? Instead did you meant to use the following assertion not all((start, end, duration)) is not None?
Also exception message is somewhat misleading.

I use Python 3.6.0, maya 0.3.2.

Thank you.

rounding precision on add subtract calls

Per #59 troubles, i did some digging, and it appears that the _epoch float is getting truncated between a now() invocation and a future add-subtract call, particularly rounding up from the 7th decimal digit. I added some unit tests which highlight this, both on the non-deterministic basis and with a forced failure. You may need to run a couple of times to duplicate. I'll submit a PR with the tests.

http://docs.python-maya.org/ is down

Going to http://docs.python-maya.org/ or the bare domain python-maya.org results in a DNS resolution error.

MayaDT - MayaDT should yield a duration

As of now, you can subtract a duration from a date, but you can't find out the duration between two different dates by subtracting one date from another.

Can't be imported when installed in a virtualenvwrapper environment

I've installed maya on OSX in a virtualenv using virtualenvwrapper with python 2.7 and 3.5. On both of them maya can't be imported even though it's dependencies can (eg humanize) ("ImportError: No module named 'maya'" is reported). I haven't had this problem with any other package in several years of using virtualenvwrapper for all of my environments, so it's quite unusual.

Installing into a manually created virtualenv works fine.

incorrect example in readme.rst

# Range of hours in a day:
 maya.interval(start=maya.now(), end=maya.now().add(days=1), interval=60*60)

no method named "interval" suppose to be intervals.

CI doesn't pick up test suite

It looks like the Jenkins is not picking up the test suite at the moment:

http://jenkins.kennethreitz.org:8080/job/maya/job/maya-pr/19/console

raumel.yaml doesn't work everywhere

We dealt with it in Cookiecutter, it doesn't work on a lot of machines. Just letting you know.

Inconsistent conversion of datetime slang

I am in Asia/Kolkata timezone and one of the test is failing due to time-zone conversion.

===================================================================================== FAILURES ======================================================================================
__________________________________________________________________________________ test_slang_date __________________________________________________________________________________

def test_slang_date():
    d = maya.when('tomorrow')

  assert d.slang_date() == 'tomorrow'

E assert 'today' == 'tomorrow'
E - today
E + tomorrow

test_maya.py:77: AssertionError

Related information when I ran dateparse.parse() and maya.when() in python shell:

>>> t = dateparser.parse('tomorrow', settings={'TIMEZONE': 'UTC', 'RETURN_AS_TIMEZONE_AWARE': True, 'TO_TIMEZONE': 'UTC'})
>>> d = maya.when('tomorrow')
>>> t
datetime.datetime(2016, 12, 27, 20, 5, 33, 716383, tzinfo=<StaticTzInfo 'UTC'>)
>>> d.datetime()
datetime.datetime(2016, 12, 27, 20, 5, 35, 304214, tzinfo=<UTC>)
>>> d.slang_date()
'today'
>>> d.local_timezone
'Asia/Kolkata'

potential spelling in README

I think these projects compliment each-other

While this is certainly at least partially true, I think you meant:

I think these projects complement each-other

rebrand to timestamps for humans?

Maya gains an extra microsecond when parsing dates after the year 2243

Consider the following program:

import datetime
import maya

d = datetime.datetime(2243, 1, 1, 0, 0, 0, 1)
print(d)
print(str(d))

parsed_d = maya.parse(str(d)).datetime()
print(parsed_d)
print(str(parsed_d))

assert d == parsed_d

2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000002+00:00
2243-01-01 00:00:00.000002+00:00
Traceback (most recent call last):
  File "counterexample.py", line 15, in <module>
    assert d == parsed_d
AssertionError

This is a bug introduced somewhere in Maya – I see that Maya is using dateutil for the main machinery of its parse function, but if I try this with dateutil everything is fine:

import datetime
from dateutil import parser

d = datetime.datetime(2243, 1, 1, 0, 0, 0, 1)
print(d)
print(str(d))

parsed_d = parser.parse(str(d))
print(parsed_d)
print(str(parsed_d))

assert d == parsed_d

2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001
2243-01-01 00:00:00.000001

Environment details:

$ pip freeze
dateparser==0.5.0
humanize==0.5.1
iso8601==0.1.11
jdatetime==1.8.1
-e [email protected]:kennethreitz/maya.git@6a4ddff215edbdce4a0f5b8bd5ba87710697b7f9#egg=maya-master
python-dateutil==2.6.0
pytz==2016.10
regex==2016.11.21
ruamel.yaml==0.13.4
six==1.10.0
tzlocal==1.3
umalqurra==0.2
wheel==0.24.0

I don’t actually care if you fix this (by 2243, I’ll either be dead, or hopefully have better things to do with my time), but having found it, I thought I’d share.

Yes, I know I’m a terrible person for finding this.

Add support for `time.time_struct` format

This looks like an awesome library, but unfortunately it doesn't seem like it supports the "9-tuple" time.time_struct format that feedparser and other older libraries use. It looks like there is a way to do from_datetime, but not from_time_struct. (For reference, I can do this in Arrow with arrow.get(my_time_struct) - but then I can't convert directly to RFCs like Maya can 😠).

Would you be interested in accepting this feature? That would allow me to use Maya as my time-core even when using older libraries.

Support year_first=False in parse

I'm having issues parsing dates that are in the format dd.mm.yy. I saw, that I can set the day_first parameter of maya.parse() to True. However this seems not to have any effect. E.g.:
2017/01/09 in "my" format would be 09.01.17. Trying the two options in maya shows me that this parameter has no effect at all:

maya.parse('09.01.17', day_first=True) == maya.parse('09.01.17', day_first=False)  # True

In pendulum, I have to set year_first = False:

pendulum.parse('09.01.17', day_first=True) == pendulum.parse('09.01.17', day_first=False)  # True
pendulum.parse('09.01.17', year_first=True) == pendulum.parse('09.01.17', year_first=False) # False

I think this could easily be resolved by adding an optional parameter year_first with default True to the parse() function and passing it on to pendulum.parse. If you like, I can create a PR

sphinx docs

Support modifiers to beginning/end of day/week/etc. like Pendulum

I'm currently struggling with figuring out the beginning/end of a dynamically provided period (day, week, month, etc.) for a given MayaDT. How about supporting modifiers for this as already in place for Pendulum or Arrow? Would you be open to a PR?

Erratic results

My first try I got an error. datetime() and iso8601() give similarly accurate results, but slang_date() fails.

import maya
maya.when('saturday').slang_date()
'Feb 03'
maya.when('saturday').datetime()
datetime.datetime(2017, 2, 4, 0, 0, tzinfo=)

Maya type validation in the MayaInterval arguments?

Should we force validation of the "Maya" type check on the arguments passed to the "MayaInterval" class? If yes, I am up for this task.

Discussion: "==" operation on MayaInterval objects

Currently == operation is checked based on the value of start and end MayaDT objects and returns True if start and end are same for the passed MayaInterval object. Code:

def __eq__(self, maya_interval):
    return (
          self.start == maya_interval.start and
          self.end == maya_interval.end
    )

However, I feel that we should make the interval check based on the duration in seconds. For example:

MayaInterval(today, tomorrow) ==  MayaInterval(yesterday, today)

should return True because the interval is same. I think this way it will be more Humanized based on the name "interval". if someone want to do check on start and end as well, they can still perform explicit check based on start and end attributes of the MayaInterval object.

If it sounds good, I can raise a PR along with allowing the other comparison operations on the MayaInterval objects.

Aligned intervals

Hi all,
What do you think how useful will it be to have a feature which aligns intervals based on a given value?

Use case

start = datetime.datetime(2017, 5, 25, 18, 21, 28)
end = datetime.datetime(2017, 5, 25, 18, 55, 28)

maya.interval(start, end, interval=FIVE_MIN, align=True)

# Then the produced sequence will look like
datetime.datetime(2017, 5, 25, 18, 20, 0)
datetime.datetime(2017, 5, 25, 18, 25, 0)
...
datetime.datetime(2017, 5, 25, 18, 55, 0)

The only restriction is that we have to support certain alignment intervals to make rounding operation easier like 5 minutes, 15 minutes, 1 hour.

If this would be anyhow useful then I can make a PR.

Thanks.

Wrapper around strftime

I'm using this library to test a REST API where one of the fields I'm submitting is a date of birth, as a string. It currently looks like:

dob = maya.when("20 years ago").datetime()
dob_str = datetime.strftime(dob, "%Y-%m-%d")

It would be nicer if I could just do something like:

dob_str = maya.when("20 years ago").as_text("%Y-%m-%d")

Would you be open to that? I suggested as_text, as I find the strftime not "for humans" (I personally had a hard time to remember it), I'm open to feedback on that name.

Provide feedback on how the time was parsed

Hi,

I've tried the library and it seems to work pretty well. A problem I noticed, though, is that I'm not able to see what was parsed and update it.

For example:

import maya

maya.when("today",timezone='America/Los_Angeles').datetime()
>>> datetime.datetime(2016, 12, 18, 18, 53, 32, 221615, tzinfo=<UTC>)

maya.when("today at 10:55 AM",timezone='America/Los_Angeles').datetime()
>>> datetime.datetime(2016, 12, 18, 18, 55, tzinfo=<UTC>)

This is great except that 'today' means now if, for my specific application, I want 'today' to mean today at midnight.

It would be really nice if the library could provide in the returned object some flags to specify it parsed a day, or parsed a time or both. So that I could eventually append something to my string (e.g: " at midnight").

maya.parse() vs maya.MayaDT.from_iso8601()

Which is the best to use? What's the advantages and disadvantages of both?

Pip failed to install maya on Windows

Tried to install, failed with a UnicodeDecodeError. Changed the terminal encoding to UTF-8, problem persisted. Am I doing something wrong? I'm using Windows 10, 64 bits, with Python 3.5.

C:\Windows\system32>pip install maya
Collecting maya
  Downloading maya-0.1.0.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\BoppreH\AppData\Local\Temp\pip-build-cuz437_p\maya\setup.py", line 26, in <module>
        long_description=open('README.rst').read(),
      File "c:\program files\python35\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 2172: character maps to <undefined>

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\BoppreH\AppData\Local\Temp\pip-build-cuz437_p\maya\

C:\Windows\system32>chcp 65001
Active code page: 65001

C:\Windows\system32>pip install maya
Collecting maya
  Using cached maya-0.1.0.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\BoppreH\AppData\Local\Temp\pip-build-044jp0hk\maya\setup.py", line 26, in <module>
        long_description=open('README.rst').read(),
      File "c:\program files\python35\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 2172: character maps to <undefined>

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\BoppreH\AppData\Local\Temp\pip-build-044jp0hk\maya\

Compatibility with/subclassing datetime

I really love that you're doing this and hope it doesn't take years off your life 😊 Assuming it all comes together, it'll be a great contribution to the Python ecosystem - it's really needed!

One problem I've come across with other datetime replacements is that they don't pass issubclass(type(d), datetime.datetime) or isinstance(d, datetime.datetime). Unfortunately, many commonly used third-party libraries (especially true for serialization) don't use duck typing the way you'd hope, and you end up having to marshall the convenience class back to a vanilla datetime object. This is a pain and leads to a lot of aggravation (for me at least)!

Philosophically, do you dislike the idea of making this (reasonably) backwards compatible with the std library datetime module? Subclassing datetime is a bit of a pain as I recall, but it may be possible to make the isinstance and issubclass checks work by (ab)using the abc module.

Interested in your thoughts, and keep fighting the good fight!

How to use EPOCH_START or should it be readonly?

I can guess EPOCH_START is intentionally exposed. How to use it properly? I see exception and strange values on random value.

>>> maya.when("tomorrow")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/akash/.pyenv/versions/vzcode/lib/python2.7/site-packages/maya.py", line 201, in when
    return MayaDT.from_datetime(dt)
  File "/home/akash/.pyenv/versions/vzcode/lib/python2.7/site-packages/maya.py", line 79, in from_datetime
    return klass(klass.__dt_to_epoch(dt))
  File "/home/akash/.pyenv/versions/vzcode/lib/python2.7/site-packages/maya.py", line 70, in __dt_to_epoch
    epoch_start = Datetime(*EPOCH_START, tzinfo=pytz.timezone('UTC'))
ValueError: year is out of range

and this one

>>> maya.EPOCH_START = (1900, 1, 1)
>>> maya.when("tomorrow")
<MayaDT epoch=3691578038.69>
>>> maya.when("tomorrow").epoch
3691578046.866085
>>> import time
>>> time.ctime(3691578046.866085)
'Tue Dec 24 19:50:46 2086'

Improve validate_type_mayadt decorator

In my opinion not only the Python object API has to be sane for humans but also (and maybe even more) the error messages.

There is this validate_type_mayadt decorator which throws a ValueError exception if the given arguments are not of type MayaDT with a somehow insufficient error message. It'd be great if it would actually tell us which operation failed because of the type mismatch.

Which operation failed?

assert (dt1 == dt2) >= 1

I see multiple solutions here:

1. pass a decorator argument describing the operation: @validate('less than')
2. get the function name from the func object within the decorator: func.__name__
3. ...

However, point 2 leads to an unhumanized error message because __lt__ would be printed - yes we could argue this exception only occurs due to programming error - It'd favor the first one though.

What do you think?

And the resulting exception should be of type TypeError

'day_first=True' should be the default for parse

maya/maya/core.py

Line 610 in 79d017f

day_first -- if true, the first value (e.g. 01/05/2016) is parsed as day (default: False)

A total of 4170 million people in the world work with the day first, whereas only 705 million uses month first. On top of that, 1970 million people use year first. day first SHOULD be the default.

https://en.wikipedia.org/wiki/Date_format_by_country#Legends

Create maya package

Currently maya is just a single .py file. This should be turned into a package.

Iterator for continuos datetimes

I recently wrote this iterator on StackOverflow for generating continuos datetime objects: https://stackoverflow.com/a/48136062/2063361

I think it will be a great fit for Maya. Should we be adding this? If so, let me know, I've a pull request ready ;)

figure out what's wrong with Python 3.6 build

https://travis-ci.org/kennethreitz/maya/jobs/235346482

I believe this is an issue with one of our dependencies, ruamel, and we may need to pin to an earlier version of it's API, as well as report this building bug to the project. It appears to only effect Python 3.

encoding argument of open() not supported under py27

maya/setup.py

Line 42 in cd7b5b4

with open(os.path.join(here, 'maya', '__version__.py'), 'r', encoding='utf-8') as f:

It looks like the encoding argument of open is not supported under python 2.7...

In fact, it breaks Circle-CI tests when trying to update the conda-feedstock.

am I missing something?

parse() doesn't properly parse exif data

@kennethreitz, as an avid photographer, I expect you of all people to ensure that exif data is properly parsed. ;-)

In this case, it appears that, if this is indeed a problem and I'm not just imagining things, it's a problem upstream. I have opened an appropriate issue with pendulum:
sdispater/pendulum#101

Support the "Anywhere on Earth" designation

https://en.wikipedia.org/wiki/Anywhere_on_Earth

Anywhere on Earth (AoE) is a calendar designation which indicates that a period expires when the date passes everywhere on Earth.

I learned about this from the PSF election, which specifies its start and end dates using this. Stack Overflow uses it for many of its events (I think, they don't use the term directly).

• MayaDT.aoe() would be true if it is that date anywhere on Earth
• MayaInterval.aoe() would be true if the interval was current anywhere on Earth

_{aoe name subject to change}

`datetime()` always setting tz to UTC even if `to_timezone` says otherwise

I find the below confusing:

In [72]: maya.when('2016-01-01').datetime(to_timezone='US/Eastern')
Out[72]: datetime.datetime(2015, 12, 31, 19, 0, tzinfo=<UTC>)

Why, if datetime() is called using to_timezone='US/Eastern', the resulting datetime object has tz_info=UTC?
Note that the resulting time is correctly UTC New Year in US/Eastern, but the tzinfo is wrong.
It's as if the resulting timezone was "replaced" rather than converted.

Incomplete ISO8601 parsing support

The support for ISO8601 parsing is incomplete. Here are some valid ISO8601 strings that will raise an error or will return the wrong result:

• 20161001T1430.4+05:30 gives 2016-10-01T08:30:30.400000+00:00 (should be 2016-10-01T09:00:00.400000+00:00).
• 2016T14
• 2016-10T14
• 2012W05
• 2012W055
• 2012007
• 2016-W07T09

maya.when() accepts string containing epoch, but computes wrong time

In [14]: epoch=str(maya.now().epoch)

In [15]: str(maya.MayaDT(epoch))
Out[15]: 'Fri, 17 Nov 2017 23:59:38 GMT'

In [16]: str(maya.when(epoch))
Out[16]: 'Sat, 18 Nov 2017 00:59:38 GMT'

I guess it should either return the same value as the constructor does, instead of apparently the value shifted by an hour (which might be timezone-dependent), or simply refuse to process this type of input (which is what maya.parse() does):

In [17]: str(maya.parse(epoch))
[...]
ParserError: Invalid date string: 1510963178

DNS does not work for http://docs.python-maya.org/

I get an ERR_NAME_NOT_RESOLVED when I try ti visit http://docs.python-maya.org/

Comparison with Arrow

What are the pros/cons against https://github.com/crsmithdev/arrow ?

Just wondering since you start a new library that may split the community between the two libraries w/o an idea which is better in which scenarios.

Just my two cents as a Python developer.

Add MayaInterval "superclass" (tm)

`MayaDT.from_struct` parses incorrectly

There seems to be a problem with the MayaDT.from_struct, where it produces an incorrect date. Here's an example of processing the same epoch time two different ways, which gets two different results.

The block

import time
import maya
import datetime as DT

e = 1507756331

# correct
t = DT.datetime.utcfromtimestamp(e)
t = maya.MayaDT.from_datetime(t)
print t

prints Wed, 11 Oct 2017 21:12:11 GMT, while the block

# incorrect
t = time.gmtime(e)
t = maya.MayaDT.from_struct(t)
print t

prints (incorrectly) Thu, 12 Oct 2017 05:12:11 GMT.

Add Internationalization

So I came across this library listening to your Podcast with Michael Kennedy and immediately loved this addition to your "python for humans" series. What discourages me though, is that there doesn't seem to be a possibility for changing the language. I saw that the humanize module you're using for the slang dates actually supports internationalization via i18n, so what steps would need to be taken to support full internationalization for this great piece of software?

RFE: add snap to time units (as in Splunk)

Hi

After having worked with splunk for a long time, I've started to love their time to snap modifiers.
http://docs.splunk.com/Documentation/SplunkCloud/6.6.1/SearchReference/SearchTimeModifiers

Would love to see maya.when('-1d@d') (yesterday at 00:00:00)

There is a library for it in python:
https://github.com/zartstrom/snaptime

Thanks for an excellent library

MayaDT isn't hashable

I'd like to be able to use a MayaDT as a key in a dict. It's not immediately clear to me what needs to be done to make MayaDT hashable.

Python 3: cmp() was removed

/cc @dgouldin

Should Return 'UTC' if get_localzone returns an invalid pytz zone name.

When I get an error when using slang_time due to tzlocal returning local as the timezone when using the python:alpine docker container.

I've also submitted an issue to the tzlocal maintainer regebro/tzlocal#44

Steps to recreate

1. Get into shell of container: docker run --rm -it python:alpine /bin/sh
2. Install dependencies: apk --no-cache add g++ musl-dev linux-headers
3. Install maya: pip install maya
4. Launch python: python
5. Import and test:

>>> import maya
>>> maya.when('2hr from now')
<MayaDT epoch=1498681971.941609>

>>> maya.when('7200 seconds from now')
<MayaDT epoch=1498682137.486269>

>>> maya.when(f'{7200} seconds from now').slang_time()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/site-packages/maya/core.py", line 259, in slang_time
    dt = self.datetime(naive=True, to_timezone=self.local_timezone)
  File "/usr/local/lib/python3.6/site-packages/maya/core.py", line 177, in datetime
    dt = self.datetime().astimezone(pytz.timezone(to_timezone))
  File "/usr/local/lib/python3.6/site-packages/pytz/__init__.py", line 181, in timezone
    raise UnknownTimeZoneError(zone)
pytz.exceptions.UnknownTimeZoneError: 'local'

There really should be a disclaimer

This project has nothing to do with Autodesk Maya........

Install issue; install error?

I've used PIP and the setup.py file to install and came across the same issue.

Searching for python-dateutilruamel.yaml
Reading https://pypi.python.org/simple/python-dateutilruamel.yaml/
Couldn't find index page for 'python-dateutilruamel.yaml' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
No local packages or working download links found for python-dateutilruamel.yaml
error: Could not find suitable distribution for Requirement.parse('python-dateutilruamel.yaml')