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

Maya – Python Datetimes for Humans

kennethreitz.org

Post reply on HN
Print view View original

61–70 of 180 posts

Re: Maya – Python Datetimes for Humans

#61

Post by masklinn »

nicpottier wrote: post #42
DasIch wrote: post #35

Earlier quoted context omitted.

The TZ database has versions and you could at least in theory expose that at a higher level in libraries.

Pretty sure pytz will hand you the appropriate timezone for a given date. There aren't version numbers after all but it can do the right thing based on when you say it is. There is some weird behaviour due to this when trying to get a timezone without an associated date as it doesn't default to now. Then again you probably have all sorts of DST bugs if you have places in your code that do that.

> Pretty sure pytz will hand you the appropriate timezone for a given date.

Correct, or more precisely for a given timezone it will use the correct offset depending on the date being converted:

    >>> format_datetime(datetime.datetime(2011, 12, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full')
    Wednesday, 14 December 2011 at 23:12:18 Apia Daylight Time
    >>> format_datetime(datetime.datetime(2012, 1, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full')
    Sunday, 15 January 2012 at 23:12:18 Apia Daylight Time

Re: Maya – Python Datetimes for Humans

#62

Post by daenney »

fnord123 wrote: post #33

Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. There are many good options to claw some performance back so it's really head-scratch inducing that someone would recognize that stdlib datetime is a dog and then wrap it instead of scrapping it.

> It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime.

I don't find it that puzzling. It's meant to help deal with timezones, efficiency isn't necessarily part of that equation.

And if I were to write a simple CLI or web app I would avoid anything that would pull in a dependency like numpy or require a C-library plus its bindings.

If you need to manipulate a huge amount of date times and this is something your app is constantly doing then sure, optimise for that.

Re: Maya – Python Datetimes for Humans

#63

Post by paulddraper »

Drdrdrq wrote: post #41

I have found that no matter what language/platform I use, the one thing that is always supported is UNIX timestamp. That makes date+time operations much easier: 1) Whenever dealing with users, use local tz. 2) Always save and manipulate in utc.

Sure, if you limit yourself to timestamps. But dates/times have much more notions than an instant. Like, that I have a recurring event every weekday at 9am local time. Or that the weekend is two days (hello, DST).

And even if you only need timestamps, "Whenever dealing with users, use local tz" isn't exactly a magic wand either.

Also, "unix timestamp" isn't exactly one data type. Sometimes you need greater precision than one second.

Re: Maya – Python Datetimes for Humans

#64

Post by jsnathan »

sametmax wrote: post #17

I wish Kenneth would have contributed to an existed project for once. Arrow and pendulum (my current favorite) have a very decent API. The later one is especially well tested for the numerous corner cases of date handling, which I doubt Kenneth got right on first try. For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives. But for date time, alternative exists and they ar…

Worrying about split effort makes most sense when the problem is large and the amount of effort dedicated to the problem is limited, or when there are network effects that come from having more people involved in the project. I don't think that applies here.

This library is not going to divert much (any?) effort that could have improved other date-time libraries.

Re: Maya – Python Datetimes for Humans

#65

Post by paulddraper »

prashnts wrote: post #46
StavrosK wrote: post #43

Earlier quoted context omitted.

I'm pretty sure that it's 23 because some time passed between keystrokes, so the delta was 23:59:50, and he only keeps the most significant digit. I had to do this exact thing yesterday for timetaco.com.

Shouldn't it be immutable? I'd expect this to be a default behaviour.

In this case, consistency would imply the immutability of time.

Re: Maya – Python Datetimes for Humans

#66

Post by xapata »

KODeKarnage wrote: post #49
stable-point wrote: post #37

Earlier quoted context omitted.

No, he doesn't: > For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives.

> I wish Kenneth would have contributed to an existed project for once. Yes, he does. He wishes Kenneth was not the same as the existing Kenneth. He emphasizes this with the "for once". Kenneth went his own way with Requests, and everyone is better off for it. You do not want a guy with that track record abandoning his work patterns. I say, let the man be. Whining about "fracturing" in open source ignores those impor…

Perhaps you misunderstood his intent with "for once". Maybe he meant "this once".

Re: Maya – Python Datetimes for Humans

#67

Post by sametmax »

KODeKarnage wrote: post #49
stable-point wrote: post #37

Earlier quoted context omitted.

No, he doesn't: > For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives.

> I wish Kenneth would have contributed to an existed project for once. Yes, he does. He wishes Kenneth was not the same as the existing Kenneth. He emphasizes this with the "for once". Kenneth went his own way with Requests, and everyone is better off for it. You do not want a guy with that track record abandoning his work patterns. I say, let the man be. Whining about "fracturing" in open source ignores those impor…

The way Kennet went is "the API is everything". Well, for requests, yes. But for maya, his API is in now way an improvment for existing tech, so we don't gain much. But there is such a thing as having too many choices, and yes, him working on this project instead of the other one will have an impact : dividing attentions, publicity, everything, tutorials, everything.

Re: Maya – Python Datetimes for Humans

#69

Post by __jal »

jsnathan wrote: post #64
sametmax wrote: post #17

I wish Kenneth would have contributed to an existed project for once. Arrow and pendulum (my current favorite) have a very decent API. The later one is especially well tested for the numerous corner cases of date handling, which I doubt Kenneth got right on first try. For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives. But for date time, alternative exists and they ar…

Worrying about split effort makes most sense when the problem is large and the amount of effort dedicated to the problem is limited, or when there are network effects that come from having more people involved in the project. I don't think that applies here. This library is not going to divert much (any?) effort that could have improved other date-time libraries.

Exactly. This isn't X.org. The author has an itch to scratch, and scratched it in exactly the right way.

Trying to funnel someone with an itch into a project is a bit like making someone on meth fill out paperwork: kills the buzz and works out poorly. And if just one human understands the nightmare of date handling a bit better, it is a positive thing for the humans.

Re: Maya – Python Datetimes for Humans

#70

Post by bpicolo »

meltingwax wrote: post #14

This is designed for programmers of user facing applications. For science and engineering, it does not address the problems, eg lack of leap seconds.

Seems like your OS / clock source should always be the guy handling leap seconds. Why would a higher-level library do it? The cases are pretty rare that you'd want to think differently about leap seconds in higher level code.
Post reply on HN