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

Introducing Times (for Python)

nvie.com

Post reply on HN
Print view View original

1–10 of 20 posts

Re: Introducing Times (for Python)

#3

Post by jessedhillon »

IMO dateutil provides this in a more transparent way by providing tzinfo subclasses:

    py> from dateutil.tz import gettz
    py> from datetime import datetime

    py> new_york = gettz('America/New York')
    py> los_angeles = gettz('America/Los Angeles')
    py> minsk = gettz('Europe/Minsk')

    py> fmt = "%Y-%m-%d %H:%M%z"
    py> datetime.now(new_york).strftime(fmt)
      '2012-02-03 01:51-0500'
    py> datetime.now(los_angeles).strftime(fmt)
      '2012-02-02 22:51-0800'
    py> datetime.now(los_angeles).astimezone(minsk).strftime(fmt)
      '2012-02-03 09:51+0300'
For me, the most annoying thing about Python is that out of the box, AFAICT, you cannot get a TZ-aware datetime. In fact, while tzinfo is part of the standard library, I don't know of any included solution for making TZ-aware datetime, short of writing your own subclasses for each timezone.

EDIT: datetime.utcnow() is TZ-aware, I meant any other timezone.

Re: Introducing Times (for Python)

#4

Post by tantalor »

I don't think "2012-02-03 09:30:00+0100" is valid ISO 8601 because of the space; it should be a "T" to be a proper "combined date and time" representation.

The date and time representations may appear in proximity to each other, often separated by a space or sometimes by other characters. In these cases they occupy two separate fields in a data system, rather than a single combined representation. This is usually done for human readability. Unlike the previous examples, "2007-04-05 14:30" is considered two separate, but acceptable, representations—one for date and the other for time. It is then left to the reader to interpret the two separate representations as meaning a single time point based on the context.

http://en.wikipedia.org/wiki/ISO_8601

That said, I prefer the "separated date and time" representation myself.

Re: Introducing Times (for Python)

#5

Post by tantalor »

I don't think its fair to say one should "never work with local times". I frequently work with "floating time", the opposite of "fixed time".

You can accept user input as (year, month, day, hour, minute, second), convert to a common timezone, and store as seconds since epoch. To display, convert back to the common timezone, but omit the timezone identifier. This is useful for events which are local for the user, since they don't care about their own timezone.

See the iCalendar spec,

They are used to represent the same hour, minute, and second value regardless of which time zone is currently being observed. For example, an event can be defined that indicates that an individual will be busy from 11:00 AM to 1:00 PM every day, no matter which time zone the person is in. In these cases, a local time can be specified.

http://www.kanzaki.com/docs/ical/dateTime.html

Re: Introducing Times (for Python)

#6

Post by jvdh »

This solves one of my problems with datetime and timezones in Python. The other being that it is totally awkward and bafflingly hard to add and substract from datetime objects.

Re: Introducing Times (for Python)

#7

Post by j2labs »

jessedhillon wrote: post #3

IMO dateutil provides this in a more transparent way by providing tzinfo subclasses: py> from dateutil.tz import gettz py> from datetime import datetime py> new_york = gettz('America/New York') py> los_angeles = gettz('America/Los Angeles') py> minsk = gettz('Europe/Minsk') py> fmt = "%Y-%m-%d %H:%M%z" py> datetime.now(new_york).strftime(fmt) '2012-02-03 01:51-0500' py> datetime.now(los_angeles).strftime(fmt) '2012-0…

I agree that dateutil is excellent. I think it's also worth mentioning how powerful dateutil's `parse()` is. You can pass virtually any string representation of a date to it and it will return a Python datetime.

Re: Introducing Times (for Python)

#8

Post by csytan »

jvdh wrote: post #6

This solves one of my problems with datetime and timezones in Python. The other being that it is totally awkward and bafflingly hard to add and substract from datetime objects.

Why do you find it difficult?

    >>> datetime.datetime.now() - datetime.timedelta(days=1)
    datetime.datetime(2012, 2, 1, 23, 33, 30, 591993)

Re: Introducing Times (for Python)

#9

Post by njharman »

csytan wrote: post #8
jvdh wrote: post #6

This solves one of my problems with datetime and timezones in Python. The other being that it is totally awkward and bafflingly hard to add and substract from datetime objects.

Why do you find it difficult? >>> datetime.datetime.now() - datetime.timedelta(days=1) datetime.datetime(2012, 2, 1, 23, 33, 30, 591993)

Doesn't do months or years. Who knows how it handles dst transitions.

I can't remember for sure but I don't think you can subtract two dates and get a delta?

Re: Introducing Times (for Python)

#10

Post by csytan »

njharman wrote: post #9
csytan wrote: post #8

Earlier quoted context omitted.

Why do you find it difficult? >>> datetime.datetime.now() - datetime.timedelta(days=1) datetime.datetime(2012, 2, 1, 23, 33, 30, 591993)

Doesn't do months or years. Who knows how it handles dst transitions. I can't remember for sure but I don't think you can subtract two dates and get a delta?

Months and years are tricky because they can consist of a variable number of days. To me, it's a better way of handling things without being ambiguous. For example, is one month from now exactly 30 days from today, or is it the next month on the same month day? It's pretty simple to do either with the datetime library.

When taking into account DST, you should first convert from local time to UTC (pytz does this) before doing your calculations, then convert it back to local time if needed.

And yes, you do get a delta when subtracting two dates.

Post reply on HN