SQL Server microsecond support (DATETIME2) was first introduced in SQL Server 2008. I can't speak on behalf of Michaya or those maintaining other SQL Server backends, but in our use cases dropping support for 2005 by switching from DATETIME to DATETIME2 exclusively would make sense. That said, we are slowly but surely becoming a PostgreSQL shop, so someone who relies on SQL Server more heavily than us may have further input. The standalone DATE column was also introduced in SQL Server 2008.
I've started a thread here to discuss with Michaya: https://github.com/michiya/django-pyodbc-azure/issues/109 On Wednesday, August 30, 2017 at 3:49:32 PM UTC-4, Tim Graham wrote: > > I guess a SQL Server expert will need to interpret > https://blogs.msdn.microsoft.com/sqlnativeclient/2008/02/27/microsoft-sql-server-native-client-and-microsoft-sql-server-2008-native-client/ > > and say exactly which SQL Server versions require the legacy datetime > handling. I see django-pyodbc-azure still supports Microsoft SQL Server > 2005 (end of extended support was April 2016) and SQL Server 2008/2008R2 > (end of mainstream support 2014, end of extended support July 2019). If > those are the only SQL Server versions that don't have microsecond support, > django-pyodbc-azure might consider dropping support for them -- doubtful if > those users require the latest version of Django, I'd guess. > > I'm not strictly opposed to keeping the supports_microsecond_precision > feature around if it's helpful for that backend, but we'll need > contributions from django-pyodbc-azure maintainers to keep it updated > (mainly with respect to using the feature to skip or change behavior in > tests). > > On Sunday, August 27, 2017 at 6:51:40 PM UTC-4, Tim Allen wrote: >> >> AFAIK, the *supports_microsecond_precision* feature is still needed by >> *django-pyodbc-azure*, because of SQL Server's, ahem, creative datetime >> fields. >> >> See: >> https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/operations.py#L474 >> >> There is a fair amount of logic needed (based off of the FreeTDS version >> and SQL Server version) necessary as well to determine whether to use SQL >> Server's *datetime* or *datetime2:* >> >> >> https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L80 >> >> https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L461 >> >> It may be possible to modify *django-pyodbc-azure* to work another way, >> but for that I would defer to Michaya. I haven't used any of the other >> pyodbc forks in years, as *django-pyodbc-azure* is very well maintained >> and supports both SQL Server and Azure. >> >> On Saturday, August 26, 2017 at 11:09:42 AM UTC-4, Tim Graham wrote: >>> >>> MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a >>> particular database version in the Django release prior to the end-of-life >>> date [0], so that would mean dropping support in Django 2.1 (released >>> August 2018). We don't have MySQL 5.5 testing in our continuous integration >>> servers and in local testing, I noticed some GIS test failures with MySQL >>> 5.5. Before investigating them, I thought I'd ask to see if there might be >>> consensus to drop support for MySQL 5.5 in Django 2.0 instead of 2.1. I'd >>> guess anyone using MySQL 5.5 users would stick with Django 1.11 LTS or >>> older. >>> >>> https://github.com/django/django/pull/8980 shows the cleanups for >>> removal of MySQL 5.5 support. Also, MySQL 5.5 is the last usage among the >>> built-in database backends for the supports_microsecond_precision >>> database feature so there's a chance that could be removed also, though I >>> found usage of it in django_pyodbc [1]. >>> >>> [0] https://code.djangoproject.com/wiki/SupportedDatabaseVersions -- though >>> we've made some exceptions like dropping support earlier for Oracle 11, >>> https://groups.google.com/forum/#!topic/django-developers/IawbBWzPXaA/discussion >>> [1] https://github.com/lionheart/django-pyodbc/issues/87 >>> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1c688f05-1a12-4f59-a77f-34cd36613c1a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
