[matplotlib-devel] Date overhaul?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recently I took a crack at fixing some of the bugs in dates.py, and it seems like there's been some talk of overhauling how dates are handled. I don't see an MEP for that, so I'm wondering if anyone can give me some more details about what the impetus was for overhauling date handling and just in general what needs to be done. I wouldn't mind taking a crack at the date handling stuff while it's still fresh in my mind. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUramTAAoJEM1U/OPZZL77t4kP/1Gj2roe2ZzGJF3u2L71p+TD gK63EKcoqLnjCs080nDfsERSSN8tG0OQvCLNcxQBV7p22rd6lMdn5MvHxYKuZVEE rD2+92f45Ql5gAw+Q8rOJKcIt/fH0MHDO5TPCJl1Mjcp1ZsQk2DO/qdOmPWlgjbg H++WWW6kXbJpBBWelNzKCR6HIhFfcEtBCNoc0MDclLm7qlxR6vGoFNBWeNptEjQ+ 4q6ZASMfIxkRKI1KpiYW+3ezMGCyw9hd/aJvj9iSti5BXL0CZHfUg1Rt7gYpsHU4 I0gSFzSIOTQb8TjKpyeD3yjxmllxgaXxdUm5i3Snp0+Cv7yWYYwAArTm/Aq6h2+z X4qaXNxys5BKqOa+oCiYLdlE/GHA+REvw4+VFoL/oOp5wVlGjaJY2jwhjhJnjvzT f4tvampwFfl0KPAm+eoqkMhqt/jjZetKwXXK+DTETO9o80yvTaM28nd1LYLD9ywN QDfVbCzrg01cQQpWVT5JtzeHoJ/4du8I+cC0VWzMM159X44GfYbtV1QUbRgdiTPh TUwDJi48Zg3eVI45L95r1eC4Q8VFzkTf59m1wve7xuVkOgNZq15BriQC7TQWWKH6 RXjTYD09PRmTyZg4YeshqLHApyAXzFYtSckHDiEFy6BPTYHsgPQcbX0U1igZUsrA 9rHjCWUZK33cLbla2CpG =RJbm -END PGP SIGNATURE- -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Date overhaul?
On 2015/01/07 11:48 AM, Paul Ganssle wrote: > Recently I took a crack at fixing some of the bugs in dates.py, and it > seems like there's been some talk of overhauling how dates are handled. > I don't see an MEP for that, so I'm wondering if anyone can give me some > more details about what the impetus was for overhauling date handling > and just in general what needs to be done. I wouldn't mind taking a > crack at the date handling stuff while it's still fresh in my mind. Paul, I think the main thing is supporting, and taking advantage of, the numpy datetime64 dtype. One thing that has held this up is that datetime64 came into numpy half-baked, and has remained experimental with known problems that need to be fixed. It looks like the core of datetime64, ignoring timezone problems, isn't going to change, so it should be possible to work with that in matplotlib. Eric -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Date overhaul?
On Wed, Jan 7, 2015 at 2:10 PM, Eric Firing wrote: > One thing that has held this up is that datetime64 > came into numpy half-baked, and has remained experimental with known > problems that need to be fixed. It looks like the core of datetime64, > ignoring timezone problems, isn't going to change, so it should be > possible to work with that in matplotlib. > you can do some googling, but the issue with timezones in datetime64 is that is _always_ uses the system timezone to translate when parsing iso strings (and bare datetime.datetime objects) without a timezone, and I'm pretty sure does somethign like that when formatting string output, too. It can be worked around if you are careful to always make it think you are working in UTC. This should change in a release or two (and I'm sorry to say that I've held that up by stalling on getting proposals properly written up), but Eric's right, the internals should stay close enough that it's worth using. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
