I'm not a fan of the name (or the entire syntax really, but the non-descriptive name is the worst bit). python is generally pretty self-documenting, but calling 'Delorean' to convert times is totally obscure. using datetime and pytz.timezone is a few too many steps at times, but at least it is readable. This is just magic.

`return utc.localize(datetime.utcnow()).astimezone(est)` is maybe a little annoying to type out, but it's obvious what it does. `return Delorean(est)` doesn't make any sense at all.

So the library does a little bit more than just deal with shifting timezones which as you put can be a little annoying.

I would take a look at the docs and see what else the library can provide before you start quoting the interface incorrectly. :)

As for the name I considered other things most lead to namespace pollution. You are right I might be able to clear up the reference for people who dont know "Back to the Future" series.

Aren't you worried that someone, somewhere might actually still own the rights to that trademark, and might, one day, come to you and ask for money? After all, you're clearly exploiting the original trademark for your own gain.

I know, I know, we all love an '80s inside-joke, but I think this is just a bit too far.

(great lib btw, datetime has always been a bloody pain, for no good reason.)

Obscure? No way. Time-travel (i.e. changing times) was the first thing I thought of.

> but calling 'Delorean' to convert times is totally obscure

Unlike calling 'pickle' to serialize...

Although now we make and eat pickled vegetables because we like the taste, pickling was originally developed in order to enable vegetables to store longer. Calling a serializer "pickle" isn't unreasonable.

It's not unreasonable, but it's still obscure. Calling a time utility Delorean isn't unreasonable, despite also being obscure.

And if i were on the mailing lists back whenever they came up with pickle, i would have told them it was a silly name too.

It will only be non-descriptive if it doesn't catch on. See, for instance, Django, Pyramid, Twisted, etc. Twisted is a particularly good example, since it shares a similar analogy: Twisted could reference the twisted pair networks use; Delorean references a time-traveling vehicle.

The name is marketing and I'm sure we're all more likely to remember because we all have a real world association with that name and back to the future.

Every time I do something involving with timezones in Python I find myself having to figure out the API again from scratch - it just doesn't fit in my brain. Having read the docs for this it appears to cover everything I ever want to do in a much more obvious way. Thanks very much!

Thank you!

Slightly off topic: does anybody know why timezones are not firmly isolated within the presentation layer (more specifically, in the string formatting functions) rather than being part of the datetime object? (datetime in Python, DateTime in C#).

In other words why this sentence could be wrong: Timezones are a presentation-layer problem! http://news.ycombinator.com/item?id=5083321

It's because timezones can be part of business logic. For example if you want to start trading at 9 London time, whether London is GMT or GMT+1 at the moment.

Or put more simply -- recurring events :)

Sibling response has already covered the direct answer, so I'll give an indirect one:

http://infiniteundo.com/post/25326999628/falsehoods-programm...

And which of those falsehoods applies here? I might be a bit thick, but just stating the falsehoods does not imply that our base temporal objects should be full of presentational properties. Or does it?

The timezone is not a "presentational property". Imagine you're billing for a service and its charge varies by the local time of day that the service is provided. You can't use GMT because customers don't think and don't expect to be charged in those terms. You can't just record a bare number, because then your reporting (and much else) doesn't add up correctly. You need a timezone in this case, and not just for presentation.

I said it was indirect.

The point is actually that it's not presentational at all. Time is far, far more complicated than your link implies; just read the comments in the HN thread: they're full of explanations for why it's oversimplifying.

Also, see: http://en.wikipedia.org/wiki/Time_standard

The essential problem comes down to the assumption that "a second" is a well-defined unit of measurement. The Wikipedia article sums it up nicely.

For applications like the vast majority of customer-facing web stuff? We rarely care about anything more precise than a minute, if that. It makes sense to isolate stuff into the presentation layer here, since the backend generally deals in milliseconds for logging anyways. But you can't generalize "customer-facing web stuff" into "anything a general purpose programming language might be used for": some of those things really care about the exactness of time and a specific time standard.

It partly because calculating time differences can depend on the timezone. If I ask "How many hours are between noon on March 9th and noon on March 11th?" the answer depends on the time zone because 2 a.m. March 10th is DST in some places.

This is very similar to Arrow. Take a look at the arrow project: https://github.com/crsmithdev/arrow You guys did almost the same sort of thing. Maybe I'm wrong and you've enhanced the functionality set even more but it could be very well worth your efforts to combine forces.

oh, thanks. that looks very good. simpler than this one, i think (at least, i can understand arrow immediately from that page).

I like all of the functionality it provides. Your project is similar in idea to my own, https://github.com/sbuss/wtftz.

I also have a half-working website at http://wtftz.com for easy timezone conversions

[after reading the very first code example]

There is a better way to write it:

  from datetime import datetime
  from pytz import timezone, utc

  EST = "US/Eastern"

  now = datetime.utcnow().replace(tzinfo=utc) # now in UTC
  return now.astimezone(timezone(EST)) # now in EST

There is no DST transitions in UTC so localize()/normalize() are unnecessary here.

The code still is not pretty and error-prone in general but there are already libraries that wrap it into easy to use interface e.g., times, arrow. They are better target to compare itself against.

I believe someone is working on writing up a more detailed post about this, but I'll throw the sanetime library out there. It's pretty slick and even has built in Django support.

https://github.com/HubSpot/sanetime https://sanetime.readthedocs.org/en/latest/

what do you mean builtin django support? its just times.

You can use SaneTimeField to store sanetime objects in your Django app.

-.-

From the docs looks like a quality solution to a real faff in python. Kudos.

Thanks! I have few of the improvement suggested by others in issues.

So I welcome any feedback people may have :)

The combination of datetime, date until and pytz is annoying, but its not clear from your example whether you're better. Why not try using you example to show many of the nuanced issues with computers representing time (that many don't know about) and how your API helps.

For example: is it 5:30 in Phoenix, Arizona?

Sorry, can't look in detail at your API - on my phone.

First, I'd like to encourage the author - please keep iterating and keep the functionality coming. There is certainly a lot that can be done to make working with dates easier.

That said, this is just not very impressive right now. The dateutil module is much more useful: http://labix.org/python-dateutil

I appreciate the encouragement. What would be much more useful is some actual feedback. :)

I have baked in some of the niceties of dateutil into Delorean, such as rrule and parse.

Please don't make it too much like dateutil; using that module requires too much doc study. I usually end up just building a few functions from scratch that do precisely what I want with datetime alone.

Which is the reason I abstracted many of the more complex features into easier, less complex and easily groked API.

I think times is a much more idiomatic and simple library to understand and use. Has one simple principle. Store all date as utc and convert to/from user's timezone only at the time of presentation.

https://github.com/nvie/times/

Arrow looks really good for this sort of thing, it's based on momentjs, which is very very nice.

[Edit add link] https://github.com/crsmithdev/arrow

This is great! I recently worked on a feature that had to do some funny time zone conversions - having this lib definitely would have helped.

Not to be confused with this Delorean: https://github.com/bebanjo/delorean