Proposal: local timezone-aware datetime fields in the admin site

[Paul Tiplady]

Timezone handling in the Django admin is quite confusing for users when the 
users are in multiple timezones, because everything in the admin site 
operates in the server's time.

Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a 
datetime field, users see the UTC time, with a note below saying "Note: You 
are 7 hours behind server time". This is better than nothing, but with a 
modern browser I believe it's possible to improve the situation. 

The ideal behaviour (I believe) would be localizing the timezones in the 
browser to the user's own time zone, and submitting back to the app using 
TZ-aware timestamp strings. It's possible to pull the TZ unambiguously from 
a modern browser: 
​https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions#Browser_compatibility#Description
.

```
Intl.DateTimeFormat().resolvedOptions().timeZone
```

Would this approach be acceptable? It seems that we'd want to default to 
the normal behaviour, and perhaps have this as config on the AdminSite 
object (since we want a way to enable this globally for sites that wish to 
use this feature).

(Originally raised here: https://code.djangoproject.com/ticket/29822, 
posting for discussion)

-- 
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/79896a0e-1338-4267-89bd-9904fca4f0d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Carlton Gibson]

Thanks for the follow-up Jon. 

I'll let Vasili follow-up on his use-case if possible/relevant. 

TBH I'm not at all sure about the SQL data files bit, which is in part why 
I asked here. 
(Encoding issues!) 

> Maybe that sentence should be rephrased to "template
files, static files, and translation catalogs".

OK, so IF it's just this, then I'm on Windows doing development in UTF-8 no 
problem (and can't really envisage doing much different as it stands) but: 

* Is that always available these days? (I'd guess yes.)
* Is is something we want to impose? Not sure. Are there people doing 
otherwise? (No idea.)

(If we can drop a setting, that'd be )

-- 
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/13cc5f04-967b-4f53-92f6-cbe155014edc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Jon Dufresne]

> So Jon, are you basically saying that Vasili's concern shouldn't come up?

Yeah, I think it shouldn't come up. But I'm not sure I fully understand
Vasili's concern . Maybe if it was more specific with more details, I could
better understand it.

Django's documentation states:

https://docs.djangoproject.com/en/dev/ref/unicode/#creating-the-database

> Make sure your database is configured to be able to store arbitrary string
> data. Normally, this means giving it an encoding of UTF-8 or UTF-16. If
you
> use a more restrictive encoding – for example, latin1 (iso8859-1) – you
won’t
> be able to store certain characters in the database, and information will
be
> lost.
>
> ...
>
> All of Django’s database backends automatically convert strings into the
> appropriate encoding for talking to the database. They also automatically
> convert strings retrieved from the database into strings. You don’t even
need
> to tell Django what encoding your database uses: that is handled
> transparently.

So, if these non-UTF-8 articles are stored in the database, this doesn't
involve FILE_CHARSET. Are the articles stored as text or binary data? If
text,
this violates existing Django documentation & assumptions. The database is
expected to be configured for UTF-8. If binary data, then the project's code
will be responsible for decoding it to a text string.

If, on the other hand, these articles are stored as files, how are they
being
loaded? If they are being loaded through a Django code path, which one such
that FILE_CHARSET is involved? Or, are these articles loaded by project code
such that the encoding can be specified.

So, IIUC, it doesn't seem like FILE_CHARSET should be involved for this use
case.

> That the whole "SQL data files" bit is misleading...?

I was unable to find any code with an interaction between FILE_CHARSET &
"SQL
data files". If it exists, do you have a link? I think this text may be
outdated or obsolete. Maybe that sentence should be rephrased to "template
files, static files, and translation catalogs".


On Wed, Oct 3, 2018 at 7:55 AM Carlton Gibson 
wrote:

> Thanks for the input everyone.
>
> So Jon, are you basically saying that Vasili's concern shouldn't come up?
> (That the whole "SQL data files" bit is misleading...?)
>
> --
> 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/6d555b4d-0b38-452c-8f40-8e690f9b33a6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CADhq2b6JU3oVYovQHG%3DO1oz0Ntw1bHTWF_iOkJcnrVPSBQh36w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Adam Johnson]

Jon's logic seems right to me. I find the lack of tests disturbing, and I
wouldn't be surprised if there were other places where django loaded files
from disk without using FILE_CHARSET when a user of that setting would
expect it to be.

On Wed, 3 Oct 2018 at 15:55, Carlton Gibson 
wrote:

> Thanks for the input everyone.
>
> So Jon, are you basically saying that Vasili's concern shouldn't come up?
> (That the whole "SQL data files" bit is misleading...?)
>
> --
> 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/6d555b4d-0b38-452c-8f40-8e690f9b33a6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM0SkC6_xPPg6ENRa%3DeHb2caj1e_rbufudhhdE%2BGM6kR7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Carlton Gibson]

Thanks for the input everyone. 

So Jon, are you basically saying that Vasili's concern shouldn't come up? 
(That the whole "SQL data files" bit is misleading...?)

-- 
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/6d555b4d-0b38-452c-8f40-8e690f9b33a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Jon Dufresne]

I'm the one that proposed this setting be removed.

The settings is used in the following areas:

> ./django/template/backends/django.py:23:
options.setdefault('file_charset', settings.FILE_CHARSET)

I suppose this is its main use case. The Django template engine defaults to
loading files from disk using the encoding specified by FILE_CHARSET. If a
project needs to load templates using a different encoding, it can continue
to do so by specifying an OPTION in the TEMPLATES setting:

TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'OPTIONS': {
'file_charset': 'latin1',
},
},
]


> ./django/core/management/commands/makemessages.py:106:encoding =
settings.FILE_CHARSET if self.command.settings_available else 'utf-8'

The makemessages management command loads files to preprocess using the
encoding specified by FILE_CHARSET.


> ./django/contrib/staticfiles/storage.py:287:content =
original_file.read().decode(settings.FILE_CHARSET)

The HashedFilesMixin loads files to preprocess using the encoding specified
by FILE_CHARSET.


> ./django/template/backends/dummy.py:31:with
open(template_file, encoding=settings.FILE_CHARSET) as fp:

The dummy template backend loads files using the encoding specified by
FILE_CHARSET. This dummy backend is used for internal testing purposes only
and is not a documented or public API. So I think it could safely be
modified without affecting projects or users.


That's it!

I think this setting has the same issue that was identified by
DEFAULT_CONTENT_TYPE. That is, if a projects sets FILE_CHARSET to a
different value, interactions with third-party apps may be problematic. The
third-party app likely encode templates and static files using UTF-8 so the
use cases above may not work properly.

Projects using a different encoding will still have a deprecation period to
see the Django warnings, adjust the setting, and re-encode files. The
removal won't be immediate. If such projects re-encode files to UTF-8
early, the projects will be both backwards and forwards compatible with
current and future Django versions.

FWIW, I was unable to find examples of a changed FILE_CHARSET by searching
GitHub.

Using a different value for FILE_CHARSET is currently untested internally
(although I believe it works as designed).

On Wed, Oct 3, 2018 at 5:03 AM Claude Paroz  wrote:

> We are not talking about general data encodings here, FILE_CHARSET is used
> to read Django text files from disk (template files, static files (css, js)
> or translation catalogs). So the question is mainly about encoding usage in
> text editors.
>
> Claude
>
> --
> 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/ba98d239-479f-4b21-b899-8c9b39b921a3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CADhq2b5Zz9zLOKVZQOJjGNogh%3DYVpAVP0-tWbeTkj3WRr6UrZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Claude Paroz]

We are not talking about general data encodings here, FILE_CHARSET is used 
to read Django text files from disk (template files, static files (css, js) 
or translation catalogs). So the question is mainly about encoding usage in 
text editors.

Claude

-- 
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/ba98d239-479f-4b21-b899-8c9b39b921a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Content types shouldn't be created on post_migrate signal

[Marcin Nowak]

]
>
> Wouldn't a workaround be to call create_contenttypes() in a RunPython in 
> your app's migration before inserting the data which depends on the content 
> types?
>
>
Thanks, but as a workaround you can do almost everything. My post is about 
proposal of fixing the issue.

BTW: RunPython() is another thing, which can break your migrations, and 
should not be used (especially not by Django internally), because it relies 
on the application layer. I discussed about it some time ago.


BR,
Marcin

-- 
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/34a6dbc5-0a1c-4c77-be76-8a878a31d336%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Content types shouldn't be created on post_migrate signal

[Adam Johnson]

Wouldn't a workaround be to call create_contenttypes() in a RunPython in
your app's migration before inserting the data which depends on the content
types?

On Wed, 3 Oct 2018 at 12:01, Marcin Nowak  wrote:

> Hello.
>
> There is a huge issue with content types framework. The data is loaded
> after every migration (post_migrate signal) automatically, and this
> approach is against db data consistency.
> The biggest problem is with data migrations, which are applied at the
> first time (on clean database). Any data migration which depends on some
> content types will not insert the data.
>
> The sequence looks like this:
>
>1. create db
>2. insert into auth_permission ...  inner join django_content_type ...
>3. post migrate: insert into django_content_type ...
>
>
> Two things are wrong:
>
>- automatic creation of content types
>- creation of content types after running migrations
>
> Solution:
>
>- creation of new app should add very first migration, which will add
>entry to the content types
>- create_contentypes handler should be removed from post_migrate signal
>
> Any data migration, which depends on some content types, should be
> declared with proper dependency. This will guarantee existence of the
> required content type entry.
>
>
> BR,
> Marcin
>
>
> --
> 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/8869b1cb-2b92-4e05-823a-92e72308fc23%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM3SsEjP8tXskwDEBnx%2BdDQpRM6412xrpmG8ifhdbP846w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django makemessages management command

[Marcin Nowak]

> You can simply do that by including a gettext_noop('your custom string') 
> line anywhere in your code (or in a specific file you create for that 
> purpose).
>
>
This is an ugly workaround.  Makemessages has other issue - it grabs 
messages from external eggs/packages, which are found in current and nested 
dirs. So beware - it can make a mess with your translations. 

BR,
Marcin

-- 
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/c733e5a3-44d1-45fa-9ef9-1596f95ebce2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Content types shouldn't be created on post_migrate signal

[Marcin Nowak]

Hello.

There is a huge issue with content types framework. The data is loaded 
after every migration (post_migrate signal) automatically, and this 
approach is against db data consistency.
The biggest problem is with data migrations, which are applied at the first 
time (on clean database). Any data migration which depends on some content 
types will not insert the data.

The sequence looks like this:

   1. create db
   2. insert into auth_permission ...  inner join django_content_type ...
   3. post migrate: insert into django_content_type ...


Two things are wrong:

   - automatic creation of content types
   - creation of content types after running migrations

Solution:

   - creation of new app should add very first migration, which will add 
   entry to the content types
   - create_contentypes handler should be removed from post_migrate signal

Any data migration, which depends on some content types, should be declared 
with proper dependency. This will guarantee existence of the required 
content type entry.


BR,
Marcin


-- 
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/8869b1cb-2b92-4e05-823a-92e72308fc23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

[Carlton Gibson]

Yes. That all sounds reasonable. 

We DO timely releases to all (and we pre-announce so people know they’re 
coming). 

It’s just this extra category of people who get the patch separately, early. 
There’s extra overhead in that. And it removes one motivation to update. 

I’m kind of inclined to advocate the RoR approach or no pre-notification, but I 
accept the argument that in big enterprises it’s just not realistic to require 
people to keep up to date. It just feels like $$$ outsourcing work they should 
be doing without actually covering the cost of that. 

I don’t see it as pay-for-access: beyond getting pre-notification you get no 
privileges. More it’s due-diligence. Using end-of-life software is arguably 
negligent. Companies doing it just need to take on the extra costs. 

However… those are just thoughts… the wind goes the other way. No problem! 

Thanks both. 

> On 3 Oct 2018, at 11:17, Markus Holtermann  wrote:
> 
> Can: yes. Should: no.
> 
> I would be really saddened to see companies being able to buy security by 
> throwing money at us. That makes us look like we can be bought. And that 
> sends the wrong signal, from my perspective. Timely security updates should 
> be available to everyone. 
> 
> Should enterprises sponsor the DSF, open source projects, or the open source 
> community in general: yes, absolutely.
> 
> What we could think about is something where companies above a yearly revenue 
> of US$ x need to sponsor in order to be on a pre-notification list. But the 
> moment we do that we put people's data at risk. A company that doesn't want 
> to pay for that sponsorship and thus won't get pre-notifications may remain 
> on an insecure version longer that they should or would if they had received 
> a pre-notification. And that's terrible as well.
> 
> My 2¢
> 
> Markus
> 
> On Wed, Oct 3, 2018, at 9:14 AM, Carlton Gibson wrote:
>> 
>> On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:
>>> 
>>> Does anyone else have feedback on this? I'd like to push it forward.
>>> 
>> 
>> I don't know if this would fly but, given that pre-notification is mainly 
>> thought of for large-scale ("enterprise"?) deployments that can't 
>> realistically "Just Update!", 
>> could we make Corporate Sponsorship of the DSF a requirement for 
>> pre-notification? (These are big companies, with payroll. A sponsorship is 
>> loose change in this context, and may at least encourage trying to 
>> update...) 
>> 
>> (Just a thought.) 
>> 
>> C.
>> 
>> -- 
>> 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/b3f4aa4c-9b00-41ac-8668-87ffa570f2d6%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
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/AAC3433C-65FF-41AD-AB40-C53EF7A6FB02%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

[James Bennett]

On Wed, Oct 3, 2018 at 2:18 AM Markus Holtermann 
wrote:

> Can: yes. Should: no.


Yeah, the idea's been proposed a couple times, and my stance on it is that
I'd quit not just the security team, but everything Django-related, if we
did that. Pay-to-play for security is not acceptable, period.

-- 
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/CAL13Cg9h1sWNFe_wEZ-eTGf0dp8RTz%2BS3aCKp3qbQCV1nz6wyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

[Markus Holtermann]

Can: yes. Should: no.

I would be really saddened to see companies being able to buy security by 
throwing money at us. That makes us look like we can be bought. And that sends 
the wrong signal, from my perspective. Timely security updates should be 
available to everyone. 

Should enterprises sponsor the DSF, open source projects, or the open source 
community in general: yes, absolutely.

What we could think about is something where companies above a yearly revenue 
of US$ x need to sponsor in order to be on a pre-notification list. But the 
moment we do that we put people's data at risk. A company that doesn't want to 
pay for that sponsorship and thus won't get pre-notifications may remain on an 
insecure version longer that they should or would if they had received a 
pre-notification. And that's terrible as well.

My 2¢

Markus

On Wed, Oct 3, 2018, at 9:14 AM, Carlton Gibson wrote:
> 
> On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:
> >
> > Does anyone else have feedback on this? I'd like to push it forward.
> >
> 
> I don't know if this would fly but, given that pre-notification is mainly 
> thought of for large-scale ("enterprise"?) deployments that can't 
> realistically "Just Update!", 
> could we make Corporate Sponsorship of the DSF a requirement for 
> pre-notification? (These are big companies, with payroll. A sponsorship is 
> loose change in this context, and may at least encourage trying to 
> update...) 
> 
> (Just a thought.) 
> 
> C.
> 
> -- 
> 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/b3f4aa4c-9b00-41ac-8668-87ffa570f2d6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/1538558277.1719089.1528965704.3DA7E4ED%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can we remove FILE_CHARSET?

[Vasili Korol]

Some Russian companies still store their old data (in databases and/or 
files) in KOI8-R. I'm not sure how many of them may be using Django, but I 
personally worked for a company in 2014-2015, that maintained a huge 
database of articles stored in KOI8-R. I can assume that, similarly, KOI8-U 
may be used in Ukraine. This is just how it turned out to be historically. 
Windows encoding CP1251 is found less often, but even in mid-2000's it was 
still competing with KOI8, so there may be some old databases in this 
encoding somewhere, too.
I would suggest keeping this setting for now.

-- 
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/13c2a00e-707d-44a6-85b6-410ed278c317%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Can we remove FILE_CHARSET?

[Carlton Gibson]

> FILE_CHARSET (default:'utf-8') 
> The character encoding used to decode any files read from disk. This 
includes template files and initial SQL data files.

Is there anywhere where this isn't UTF-8? (Or can't be decreed to be so?)

Jon has a suggestion to remove it:

Ticket: https://code.djangoproject.com/ticket/29817
PR: https://github.com/django/django/pull/10472/

Claude on GitHub: 


> You preach to a convert! However it's not about not being able to encode 
in UTF-8, but about the common file encoding on some platforms, especially 
Windows. I'm not using Windows for a long time now, so I can't say if UTF-8 
is a common encoding nowadays or if it needs a special handling (say change 
a program preference) in most Windows text editors.

Do you know about this? Can I ask for your input here? 

Thanks! 

-- 
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/38cf5604-106b-4e06-a1f0-796b7bd071c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

[Carlton Gibson]

On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:
>
> Does anyone else have feedback on this? I'd like to push it forward.
>

I don't know if this would fly but, given that pre-notification is mainly 
thought of for large-scale ("enterprise"?) deployments that can't 
realistically "Just Update!", 
could we make Corporate Sponsorship of the DSF a requirement for 
pre-notification? (These are big companies, with payroll. A sponsorship is 
loose change in this context, and may at least encourage trying to 
update...) 

(Just a thought.) 

C.

-- 
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/b3f4aa4c-9b00-41ac-8668-87ffa570f2d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.