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

161–170 of 180 posts

Re: Maya – Python Datetimes for Humans

#161

Post by deathanatos »

mjevans wrote: post #127
dom0 wrote: post #21

> Datetimes are a headache to deal with in Python, especially when dealing with timezones, especially when dealing with different machines with different locales. Anything with date/time calculations is always a pain, probably doesn't really have much to do with the library/language itself, but that the abstraction level that's used (and typically used in other libraries) means that the complexities of calendar and t…

If you're mixing UTC and DST you are doing something wrong.

I think what dom0 means is a situation like the following. Say you want to schedule, on a calendar, an event that happens daily at 2PM in your local timezone, say America/New_York. If you record that even as happening at 2200 UTC each day, when DST rolls around, it'll shift to 1PM or 3PM in the local timezone. This is not what the user wants.

Here, despite storing everything in UTC and attempting to apply DST as late as possible as if it were a "display issue" — normally the right thing — here results in the wrong outcome.

Re: Maya – Python Datetimes for Humans

#162

Post by KODeKarnage »

sametmax wrote: post #67
KODeKarnage wrote: post #49

Earlier quoted context omitted.

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

> him working on this project instead of the other one will have an impact : dividing attentions, publicity, everything, tutorials, everything.

First of all, lets acknowledge that nobody really has the right to tell Kenneth what he should do.

Having "too" many choices is merely a symptom of not having the best choice. Remember back when Google hadn't won the search engine war? Imagine someone had told the google-guys that they should just contribute to DogPile or AskJeeves? How backwards would those guys seem?

And it isn't a choice of him working on his project, or some existing one. The choice is him working on this project or not at all. And given that he has a proven track record at producing brilliant stuff when he goes his own way, we would all be better off letting him get on with it.

Re: Maya – Python Datetimes for Humans

#163

Post by jasoncchild »

tedmiston wrote: post #146
jasoncchild wrote: post #145

Earlier quoted context omitted.

Idk, pointing to issues like deep dependency within the Node community isn't the best argument. It's healthy to be skeptical of dependencies imo, especially in light of issues like the infamous left pad problem.

My comment wasn't about deep dependencies; it was about parent suggesting 200 lines is too few to be a legitimate library.

Ah, I see. Noted!

Re: Maya – Python Datetimes for Humans

#164

Post by deathanatos »

masklinn wrote: post #152
meltingwax wrote: post #135

Earlier quoted context omitted.

When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. You could use time_t underneath, if that's what you really wanted to do. As my co-worker once put it, "time is a four letter word." At the very least, there is a need for showing the occasional 61st second of a minute, and adding a time and timedelta where leap seconds is taken into ac…

> When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. I still don't understand what you mean. > You could use time_t underneath, if that's what you really wanted to do. Well you've got unix timestamp (UTC) which "skips" leap seconds but as a result is very easy to map to "human time", or you've got TAI[0] which includes leap seconds but…

What I believe he's trying to say is that sometimes, you need a library capable of the following:

    2016-12-31T23:59:30Z + 60s == 2017-01-01T23:59:29Z
(The above is a true statement, due to the presence of a leap second in the duration.)

Python does not do this:

  In [5]: datetime.datetime(2016, 12, 31, 23, 59, 30, tzinfo=pytz.UTC) + datetime.timedelta(seconds=60)
  Out[5]: datetime.datetime(2017, 1, 1, 0, 0, 30, tzinfo=)
(Nor does Arrow. Maya doesn't really seem to support arithmetic on a MayaDT short of converting to a datetime, so in that regard, it behaves like Python.) The above output is not terribly surprising, as Python and a lot of software tend to follow Unix/POSIX time. Whether it is "right" depends.

You also mix up the various timescales:

> Well you've got unix timestamp (UTC) which "skips" leap seconds

Unix/POSIX time might not skip leap seconds; some will repeat a second as the leap second occurs. (I.e., while UTC counts 23:59:59, 23:59:60, 00:00:00, POSIX will count 23:59:59, 23:59:59, 00:00:00.) Linux falls into this latter case, I believe, during which time adjtimex() will return TIME_OOP.

However, Unix/POSIX time is not UTC. UTC never "skips" leap seconds, as leap seconds are an inherent property of UTC.

> or you've got TAI which includes leap seconds

TAI does not include leap seconds[1]:

> the name International Atomic Time (TAI) was assigned to a time scale based on SI seconds with no leap seconds.

> TAI is exactly 36 seconds ahead of UTC. The 36 seconds results from the initial difference of 10 seconds at the start of 1972, plus 26 leap seconds in UTC since 1972.

UTC: has leap seconds as a property of how it works

TAI: does not include leap seconds

POSIX/Unix time: an integer that can be mapped to UTC except during leap seconds, where it becomes ugly (unless you know if TIME_OOP was set, in which case it can still be mapped to UTC).

> but [TAI] doesn't allow dates in the future since you don't know where and when new leap seconds will be added long in advance, and now you need regular updates/permanent connectivity so you can remap TAI onto human time

With the above, it should be obvious that this is a property of UTC, not TAI. TAI timestamps in the future should be stable/usablable without surprises. UTC's might not be due to leap seconds.

[1]: https://en.wikipedia.org/wiki/International_Atomic_Time

Re: Maya – Python Datetimes for Humans

#165

Post by [deleted] »

masklinn wrote: post #152
meltingwax wrote: post #135

Earlier quoted context omitted.

When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. You could use time_t underneath, if that's what you really wanted to do. As my co-worker once put it, "time is a four letter word." At the very least, there is a need for showing the occasional 61st second of a minute, and adding a time and timedelta where leap seconds is taken into ac…

> When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. I still don't understand what you mean. > You could use time_t underneath, if that's what you really wanted to do. Well you've got unix timestamp (UTC) which "skips" leap seconds but as a result is very easy to map to "human time", or you've got TAI[0] which includes leap seconds but…

[deleted]

Re: Maya – Python Datetimes for Humans

#166

Post by jeffbr13 »

BoppreH wrote: post #149
jeffbr13 wrote: post #148

Earlier quoted context omitted.

Python already contains separate date and time objects for this purpose[1][2]! [1]: https://docs.python.org/3/library/datetime.html#date-objects [2]: https://docs.python.org/3/library/datetime.html#time-objects

I think that would only work for day long ranges. What if I want the events that happened in the last hour, or that are scheduled for May?

Combine pure dates and times with timedelta[1]? Python's multiple comparison expressions help here too.

For events in the last hour, the following expression should evaluate to True:

    (datetime.now() - timedelta(hours=1))
Checking whether event_datetime is within May of the current year is a bit more involved, but you may not need to convert everything to a date (would have to check in an interpreter):

     date.today().replace(month=5, day=1)
The point is that the language already has good support for sensible time operations, but it's parsing is weak. And there's Arrow for that[2]!

[1]: https://docs.python.org/3/library/datetime.html#timedelta-ob... [2]: http://arrow.readthedocs.io/en/latest/

Re: Maya – Python Datetimes for Humans

#167

Post by TylerE »

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.

Or perhaps even better use conditional imports and do progressive fallback.

Re: Maya – Python Datetimes for Humans

#168

Post by mjevans »

deathanatos wrote: post #161
mjevans wrote: post #127

Earlier quoted context omitted.

If you're mixing UTC and DST you are doing something wrong.

I think what dom0 means is a situation like the following. Say you want to schedule, on a calendar, an event that happens daily at 2PM in your local timezone, say America/New_York. If you record that even as happening at 2200 UTC each day, when DST rolls around, it'll shift to 1PM or 3PM in the local timezone. This is not what the user wants. Here, despite storing everything in UTC and attempting to apply DST as late…

In your example what I said is still true.

The user didn't want a precise coordinated time (DST is not a factor for storage/recall); the user wanted a fuzzy reference to local time (DST is a factor for evaluation).

Re: Maya – Python Datetimes for Humans

#169

Post by toyg »

vacri wrote: post #138
masklinn wrote: post #57

Earlier quoted context omitted.

Except (2) doesn't necessarily work when events are local and you factor in timezone variations (both DST and actual TZ changes). There are classes of events where you're much better off with zoned local dates e.g. local meetings. Example: in early 2011, Samoa announced that on December 29th at midnight local they would switch their timezone offset from -11 to +13. Before that announcement (or at least before your ti…

Using one of the most extreme edge cases is not a good argument. How often is Samoa (or another small dateline-neighbour country) going to 'jump sides'?

Timezones change all the time. There are almost 200 countries in the world, some so large that even their sub-states can and do change timezone rules on their own (US, Russia, India, China...). This is why Linux distributions have a dedicated package listing timezone info that is updated almost weekly, and Windows has similar arrangements.

Any solid datetime implementation better consider that time is not, in fact, immutable - even UTC can and will shift here and there.

Re: Maya – Python Datetimes for Humans

#170

Post by toyg »

ak217 wrote: post #120

I like Kenneth's work, but "I wrote a new datetime library" is a cliche now. We have datetime, dateutil, pytz, babel, arrow, pendulum, delorean, a bunch of lesser known stuff, and now this. I have yet to see the need for anything but the first four.

Seems to be a case of "Python Web Framework"-itis: it's relatively simple to hash up something from scratch that covers one's particular use-case (in this case, it seems, a slightly smarter parser), but it's actually hard to properly cover all use-cases.

This is what happened with Python web frameworks, a scene which was heavily fragmented before Django and Flask basically solidified the two main communities of users ("I need everything and the kitchen sink" / "I need the bare minimum to get going"). The same happened with urllib2/urllib3/httplib/ etc before Requests appeared.

Nobody seems to have pulled this trick for datetime libraries yet, so here's a new contestant.

Post reply on HN