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.
Delorean – datetime conversions in Python
21–30 of 42 posts
Re: Delorean – datetime conversions in Python
#22Slightly 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...
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?
Re: Delorean – datetime conversions in Python
#23Earlier quoted context omitted.
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.
Re: Delorean – datetime conversions in Python
#24Slightly 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 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.
Re: Delorean – datetime conversions in Python
#25First, 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.
Re: Delorean – datetime conversions in Python
#26Earlier quoted context omitted.
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.
Re: Delorean – datetime conversions in Python
#27Not to be confused with this Delorean: https://github.com/bebanjo/delorean
Re: Delorean – datetime conversions in Python
#28Earlier quoted context omitted.
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?
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.
Re: Delorean – datetime conversions in Python
#29This 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).
Re: Delorean – datetime conversions in Python
#30Earlier quoted context omitted.
> 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.