On 13/10/2012 00:37, Ethan Gutmann wrote: > On Oct 12, 2012, at 4:15 PM, Mark Lawrence wrote: > >> On 12/10/2012 20:38, Ethan Gutmann wrote: >>> >>> I'm a little confused by this attitude. I recognize that there are issues >>> around dates, I've written a few date libraries myself to get around insane >>> excel date issues (pop quiz for anyone at MS, was 1900 a leap year?) or >>> just to simplify APIs for my own use. But do neither of you think that >>> nanoseconds are important to scientists? I know of enough projects that >>> work with pico (and a few with femto) seconds. Even though I often work >>> with climate data covering ~100s of years and used to work with geologic >>> data covering ~billions of years, I may start working with raw laser data >>> for distance measurements where nanoseconds can be a pretty big deal. >>> These data would be collected over a few years time, so a date utility that >>> can handle that scale range would be useful. I guess I'll be > writing my own date/time library again and hacking together some way of > plotting data in a meaningful way in matplotlib. >>> >>> Don't get me wrong, matplotlib shouldn't have to reinvent the wheel here, >>> but claiming that nobody could possibly care about 1e-12 seconds seems a >>> little provincial. My apologies if that is not how the above statements >>> were intended. >>> >>> regards, >>> Ethan >>> >>> >> >> I actually said "What percentage of computer users wants a delta of >> 1e-12? I suspect that the vast majority of users couldn't care two >> hoots about miniscule time deltas in a world where changing time zones >> can cause chaos...". >> >> How does this translate into "claiming that nobody could possibly care >> about 1e-12 seconds seems a little provincial"? >> >> -- >> Cheers. >> >> Mark Lawrence. > > Like I said, my apologies if I mis-interpreted. To me the statement "the > vast majority of users couldn't care two hoots..." *implies* "since almost > nobody needs this we won't worry about it", especially when it is in response > to someone who felt this was an important feature: > "A delta of 1e-9 is the *least* I'd expect. Maybe even 1e-12. ". > My response was as much an issue with how I perceived the tone as anything > else (obviously, tone doesn't cary well over email ;) ) > > Don't get me wrong, I realize there are bigger fish to fry. I just want add > a vote that 1E-12 seconds (and less) can indeed be important to a significant > number of people. I suspect that many experimental physicists would be > unable to use a time utility that can't handle those timescales. Many of > them will simply write there own utility, but then if they start running into > any of the longer time scale issues e.g. leap years/seconds etc. they end up > having to reinvent the wheel. Others have also pointed out that > databases[1], network packets and stock trading transactions[2] may care > about nanoseconds. > > [1]http://code.activestate.com/lists/python-dev/117090/ > [2]http://code.activestate.com/lists/python-dev/117091/ > > I'm glad to see that others are thinking about this and that future python > versions may get down to nanosecond (or better?) resolution, though I haven't > found the PEP for it yet. Guido seems to have given his approval for more > work on the matter at least : > http://code.activestate.com/lists/python-dev/117147/ > > PEP 418 mentioned before doesn't mention the date time class as far as I can > tell. http://www.python.org/dev/peps/pep-0418/ > > regards, > Ethan >
I know that there are 1000s times more people dealing with order processing systems who want to know the number of working days including bank holidays in which to get their order processed than experimental physicists playing with relatively nothing. You only have to look at the UK for real world problems like this as bank holidays are different in England and Wales when compared to both Scotland and Northern Ireland. From PEP 418 "This PEP proposes to add time.get_clock_info(name), time.monotonic(), time.perf_counter() and time.process_time() functions to Python 3.3." I've checked and the functions have all been implemented in Python 3.3. If they're inadequate patches are always welcome. -- Cheers. Mark Lawrence. ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
