Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pendulum – Python datetimes made easy

github.com

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Pendulum – Python datetimes made easy

#51

Post by tedmiston »

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…

That's very interesting. I wonder if the popular datetime libraries issued a patch for this case?

Re: Pendulum – Python datetimes made easy

#52

Post by masklinn »

tedmiston wrote: post #51
masklinn wrote: post #48

Earlier quoted context omitted.

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…

That's very interesting. I wonder if the popular datetime libraries issued a patch for this case?

tz libraries shipped a new version for the tzdata update, as they do more or less every time the database is updated (monthly or so). 9 months lead time is actually pretty good, consider: April 29th the Egyptian government announced they'd go on DST on July 7th, with no further information until June 27th when Parliament proposed to abolish DST and passed a (apparently non-binding) vote for that on June 28th, following which the Egyptian government announced they wouldn't go on DST after all on July 4th.

Re: Pendulum – Python datetimes made easy

#53

Post by masklinn »

jsmeaton wrote: post #50
masklinn wrote: post #48

Earlier quoted context omitted.

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.

> 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.

Yep, or if a DST change was added or rescinded (which can happen on surprisingly short orders, many governments love fucking up with DST, this year 2016 we got an infirmation of Egyptian DST with 3 days lead time).

Re: Pendulum – Python datetimes made easy

#54

Post by AdamN »

What about precision? There is the Date object with day-precision and the Datetime object with microsecond precision ... but nothing else. There's no canonical way in Python with any library that I know of to say "July, 2013" or even "12:15pm". The former will simply put in July 1st and the latter will put in seconds and microseconds implying precision that doesn't exist.

Anybody know of an elegant solution/library or even a library that would be open to including such a concept?

Re: Pendulum – Python datetimes made easy

#55

Post by sdispater »

lukasgraf wrote: post #34
Walkman wrote: post #28

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. 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…

I tend to agree. Obviously automatic normalisation is the correct thing to do when doing arithmetic that crosses DST-rollover boundaries (this is what the Python stdlib gets wrong), but I don't think it should be done (by default) upon creation with a location-based TZ specification: pendulum.create(2016, 10, 30, 2, 30, 00, 0, 'Europe/Paris') is ambiguous, and pendulum.create(2016, 3, 27, 2, 30, 00, 0, 'Europe/Paris'…

I am not too kind on raising an error by default (which pytz does not do by default either but rather return the pre-DST transition time).

I think the best thing to do here is keep the current behavior (post-DST) but with an option to choose what you want exactly (post-DST, pre-DST)

Re: Pendulum – Python datetimes made easy

#56

Post by AdamN »

jsmeaton wrote: post #25
sdispater wrote: post #2

Pendulum is a new library for Python to ease datetimes, timedeltas and timezones manipulation. It is heavily inspired by [Carbon]( http://carbon.nesbot.com ) for PHP. Basically, the Pendulum class is a replacement for the native datetime one with some useful and intuitive methods, the Interval class is intended to be a better time delta class and, finally, the Period class is a datetime-aware timedelta. Timezones are…

Cool library, I'll definitely be looking into this more closely in the future. The automatic handling of ambiguous time during timezone transitions is curious. As an example, Django punts on automatic handling and requires a user to choose between pre and post transition (I wrote the is_dst handling): https://github.com/django/django/blob/19e20a2a3f763388bba926... What if you were to begin with a time at 3:30 and the…

PEP 495 - Local Time Disambiguation (folding) handles this in Python 3.6 quite elegantly:

https://www.python.org/dev/peps/pep-0495/

It adds an extra attribute 'fold' that can be '0' (the default) for normal times and '1' for the later version with that same local time representation in the case of the clock going backwards.

Re: Pendulum – Python datetimes made easy

#57

Post by sdispater »

Shish2k wrote: post #47

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…

I agree but this is an optional feature which might cover most of the developers needs. But, if not, it's configurable:

    pendulum.set_weekend_days([pendulum.SUNDAY])

Re: Pendulum – Python datetimes made easy

#58

Post by jonathanpoulter »

abuckenheimer wrote: post #44

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…

I also really like the Timestamp class, are the obvious reasons not to use it?

Re: Pendulum – Python datetimes made easy

#59

Post by dvl »

ak217 wrote: post #10
josefdlange wrote: post #7

What benefits does this have over [Delorean]( http://delorean.readthedocs.io/en/latest/ )? The README for Pendulum seems to show me one feature Delorean doesn't explicitly have -- `is_weekend()` -- otherwise these libraries are conceptually very similar. I do agree that this (and Delorean) is a usability improvement over `datetime` and perhaps even Arrow (though I'm not tremendously familiar with Arrow).

So far I haven't seen either of these libraries do substantially better than datetime+dateutil+pytz at anything they claim to be good at.

I'm happy to not have to import 3 libraries anymore (2 that aren't part of standard library) to see if one date is greater than another or to add few days to a date.

Re: Pendulum – Python datetimes made easy

#60

Post by jbg_ »

calpaterson wrote: post #37
forgotpwtomain wrote: post #3

Python stdlib datetime/time/calendar libs are junk. That one constantly has to read obscure function signatures in the docs to do rather obvious things is just awful. On the otherhand if you've e.g. Ruby/Rails datetime handling than you get used to reasonable things working ( such as Time.now + 1.day ) that Arrow doesn't handle well. As a matter of fact Arrow got rid of DT deltas and seemingly made the situation wors…

>>> from datetime import datetime, timedelta >>> datetime.now() - (datetime.now() + timedelta(days=1)) datetime.timedelta(-2, 86399, 999969)

I’m not entirely sure what you were trying to demonstrate, but clearly the result of datetime.now() changes between the two invocations (it has microsecond precision).

Try:

    >>> from datetime import datetime, timedelta
    >>> now = datetime.now()
    >>> now - (now + timedelta(days=1))
    datetime.timedelta(-1)
Post reply on HN