Pendulum – Python datetimes made easy • Hacker News Board

Re: Pendulum – Python datetimes made easy

#41

Post by koliber » Wed, Aug 17, 2016, 10:57 AM UTC

Looks like a nice polished interface. I am wondering what is Pendulum's policy on invalid input. The examples illustrate the inconsistent approach to invalid inputs:

In some cases it guesses what you meant:

    >>> pendulum.create(2013, 3, 31, 2, 30, 0, 0, 'Europe/Paris')
    '2013-03-31T03:30:00+02:00' # 2:30 does not exist (Skipped time)

In other cases, it raises exceptions:

    pendulum.parse('2016-06-31')
    # ValueError: day is out of range for month

Re: Pendulum – Python datetimes made easy

#42

Post by jgalt212 » Wed, Aug 17, 2016, 10:57 AM UTC

Animats wrote: post #30

This area is prone to severe bikeshedding. Back in 2012, I filed a Python bug, "datetime: add ability to parse RFC 3339 dates and times"[1] RFC 3339 timestamps appear in email, RSS feeds, etc. The datetime library could output them, but not parse them. There are at least seven parsing functions in PyPi for them, and each has some major problem. There have been steady discussions of this issue for almost four years no…

> RFC 3339 timestamps appear in email

Where exactly in email to do they appear? In the header, it's been my experience they all conform to the RFC 2822 spec, and could be parsed with the standard library function email.utils.parsedate_tz[1].

[1] https://docs.python.org/2/library/email.util.html#email.util...

Re: Pendulum – Python datetimes made easy

#43

Post by baq » Wed, Aug 17, 2016, 12:00 PM UTC

koliber wrote: post #41

Looks like a nice polished interface. I am wondering what is Pendulum's policy on invalid input. The examples illustrate the inconsistent approach to invalid inputs: In some cases it guesses what you meant: >>> pendulum.create(2013, 3, 31, 2, 30, 0, 0, 'Europe/Paris') '2013-03-31T03:30:00+02:00' # 2:30 does not exist (Skipped time) In other cases, it raises exceptions: pendulum.parse('2016-06-31') # ValueError: day i…

+1, i'd expect a ValueError in the first example

Re: Pendulum – Python datetimes made easy

#44

Post by abuckenheimer » Wed, Aug 17, 2016, 12:04 PM UTC

I know pandas is a bit meaty for a date time library if you don't already use it but their Timestamp class is awesome. String parsing is a breeze, offsets and timezones are easy and then there's a ton of support for time series.

    In [34]: pd.Timestamp('2016-08') == pd.Timestamp('2016.08') == pd.Timestamp('2016/08') == pd.Timestamp('08/2016')
    Out[34]: True
    
    In [38]: pd.Timestamp('2016') == pd.Timestamp(datetime.datetime(2016,1,1))
    Out[38]: True
    
    In [49]: pd.Timestamp('2016') + pd.offsets.MonthOffset(months=7) == pd.Timestamp('2016-08')
    Out[49]: True
    
    In [52]: pd.Timestamp.now()
    Out[52]: Timestamp('2016-08-17 08:01:07.576323')
    
    In [53]: pd.Timestamp.now() + pd.offsets.MonthBegin(normalize=True)
    Out[53]: Timestamp('2016-09-01 00:00:00')

see http://pandas.pydata.org/pandas-docs/stable/timeseries.html for more examples

Re: Pendulum – Python datetimes made easy

#45

Post by fragmede » Wed, Aug 17, 2016, 12:07 PM UTC

Animats wrote: post #30

This area is prone to severe bikeshedding. Back in 2012, I filed a Python bug, "datetime: add ability to parse RFC 3339 dates and times"[1] RFC 3339 timestamps appear in email, RSS feeds, etc. The datetime library could output them, but not parse them. There are at least seven parsing functions in PyPi for them, and each has some major problem. There have been steady discussions of this issue for almost four years no…

Past bikeshedding, there's also the long list of myths programmers believe about time[1] and the crowd-sourced followup[2]. Pendulum inherits from datetime in the stdlib, but I'm unsure how well either of those address the issues raised (or even if it's possible - some need to be addressed by the code that uses pendulum/datetime).

[1] http://infiniteundo.com/post/25326999628/falsehoods-programm... [2] http://infiniteundo.com/post/25509354022/more-falsehoods-pro...

Re: Pendulum – Python datetimes made easy

#46

Post by masklinn » Wed, Aug 17, 2016, 12:16 PM UTC

ak217 wrote: post #19

antar wrote: post #11

Earlier quoted context omitted.

arrow.get(value).humanize() How can I do this with datetime+dateutil+pytz?

I was talking about delorean and pendulum (I think josefdlange edited his comment). I agree that arrow's multi-locale natural language renderer does add a lot of value. (Although I'd argue it should be unbundled into its own module, instead of Arrow trying to replace a ton of datetime/dateutil functionality.)

> I agree that arrow's multi-locale natural language renderer does add a lot of value. Although I'd argue it should be unbundled into its own module

http://babel.pocoo.org/en/latest/api/dates.html

humanize is apparently a human-readable directioned delta, so that'd be format_timedelta(delta, add_direction=True)

    >>> print format_timedelta(ref - datetime.now(), add_direction=True)
    1 hour ago
    >>> print format_timedelta(ref - datetime.now(), add_direction=True, locale='zh')
    1小时前
    >>> print format_timedelta(ref - datetime.now(), add_direction=True, locale='ru')
    1 час назад

Re: Pendulum – Python datetimes made easy

#47

Post by Shish2k » Wed, Aug 17, 2016, 12:16 PM UTC

Good to see we're starting to come close to getting dates and times handled according to the rules (I won't say sensibly, because the rules themselves aren't sensible). But then we start over-reaching and trying to handle social constructs built on top of dates and times, which is even more of a mess D:

Eg, spot the error:

    _weekend_days = [SATURDAY, SUNDAY]
    date.is_weekend = date.day in _weekend_days

Hint: https://en.wikipedia.org/wiki/Workweek_and_weekend#Around_th...

(TIL one country doesn't even have consecutive weekend days)

Re: Pendulum – Python datetimes made easy

#48

Post by masklinn » Wed, Aug 17, 2016, 12:27 PM UTC

jsmeaton wrote: post #26

tedmiston wrote: post #23

I've been happily using django.utils.timezone for a while now and doing everything on the backend in UTC. For any user-facing timestamps, to some degree I'd rather keep that in the front end and a separate concern from my API. Not saying storing user timezone and converting on the backend is bad; but this is simpler when localized timestamps aren't a core part of my app.

Yes, always work in UTC. But you could use this library to convert user provided naive datetimes to UTC, and datetimes coming from the database into localised datetimes. Converting from/to timezones other than UTC in Django isn't as nice as it could be.

No, don't always work in UTC.

If a Samoan user told you to record an event for January 1st 2012 on January 1st 2011, if you stored the date in UTC would have reminded them on January 2nd 2012 (all local).

Because in May 2011 Samoa announced they were going to skip a local day and move across the international date line. So 2011-12-30T09:00:00 UTC was 2011-12-29T23:00:00 Pacific/Apia, but 2011-12-30T10:00:00 UTC was 2011-12-31T00:00:00 Pacific/Apia.

Re: Pendulum – Python datetimes made easy

#49

Post by tedmiston » Wed, Aug 17, 2016, 12:58 PM UTC

Walkman wrote: post #28

sdispater wrote: post #24

Earlier quoted context omitted.

I see what you mean but as soon as you deal with timezone-aware datetimes you don't really have a choice, if an hour has been skipped, it simply doesn't exist. What is important here, I think, is that any time arithmetic is not affected by this normalization, so if you add an hour the difference will be an hour, so you don't really have to think about it.

> I see what you mean but as soon as you deal with timezone-aware datetimes you don't really have a choice, if an hour has been skipped, it simply doesn't exist. So somebody clearly made a mistake (either the user or the programmer not checking the input) which you can't automagically fix. Well, at least, it's a terrible idea. I understand the intent of helping them, but you make more harm this way. It's also against…

A cursory glance at Django's timezone docs says pytz (which is optional but recommended) raises an exception when a time doesn't exist due to DST.

> Unfortunately, during DST transitions, some datetimes don’t exist or are ambiguous. In such situations, pytz raises an exception. Other tzinfo implementations, such as the local time zone used as a fallback when pytz isn’t installed, may raise an exception or return inaccurate results. That’s why you should always create aware datetime objects when time zone support is enabled.

https://docs.djangoproject.com/en/1.10/topics/i18n/timezones...

Re: Pendulum – Python datetimes made easy

#50

Post by jsmeaton » Wed, Aug 17, 2016, 1:03 PM UTC

masklinn wrote: post #48

jsmeaton wrote: post #26

Earlier quoted context omitted.

Yes, always work in UTC. But you could use this library to convert user provided naive datetimes to UTC, and datetimes coming from the database into localised datetimes. Converting from/to timezones other than UTC in Django isn't as nice as it could be.

No, don't always work in UTC. If a Samoan user told you to record an event for January 1st 2012 on January 1st 2011, if you stored the date in UTC would have reminded them on January 2nd 2012 (all local). Because in May 2011 Samoa announced they were going to skip a local day and move across the international date line. So 2011-12-30T09:00:00 UTC was 2011-12- 29 T23:00:00 Pacific/Apia, but 2011-12-30T10:00:00 UTC was…

Wow, that's a really interesting case. I guess the same thing would happen whenever an offset was adjusted after you store a value in UTC intended for another timezone. I don't think this is even supported by Django - all times are converted to UTC on entry to the database.