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

Delorean – datetime conversions in Python

delorean.readthedocs.org

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Delorean – datetime conversions in Python

#11

Post by calpaterson »

opminion wrote: post #5

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.

Re: Delorean – datetime conversions in Python

#12

Post by calpaterson »

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.

Re: Delorean – datetime conversions in Python

#13

Post by apaprocki »

calpaterson wrote: post #11
opminion wrote: post #5

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 :)

Re: Delorean – datetime conversions in Python

#15

Post by dorkrawk »

notatoad wrote: post #4

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 calling 'Delorean' to convert times is totally obscure

Unlike calling 'pickle' to serialize...

Re: Delorean – datetime conversions in Python

#16

Post by EliRivers »

notatoad wrote: post #4

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…

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

Re: Delorean – datetime conversions in Python

#17

Post by SoftwareMaven »

notatoad wrote: post #4

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…

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.

Re: Delorean – datetime conversions in Python

#19

Post by saraid216 »

opminion wrote: post #5

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

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

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

Re: Delorean – datetime conversions in Python

#20

Post by maw »

dorkrawk wrote: post #15
notatoad wrote: post #4

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 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.
Post reply on HN