Dates on Projects don't play nice with dd/mm/yyyy format

[armstrongcyber]

The date handler on the projects does not seem to like those that natively use ISO8601 type dates (yyyy/mm/dd or dd/mm/yyyy).

So when I try to add dates as per the displayed (mm/dd/yyyy) mask the system rejects the input.

To correct this I add a EU type date (dd/mm/yyyy) and the system accepts it and shows it as 9 Feb 2019 in the date picker window and then as 2nd Sept on the Project summary.

[chrismaddalena]

Yes, Django's date fields use the mm/dd/yyyy format. We have some placeholder text in the fields to act as a reminder and the datepickers should save you from needing to type them in manually in Django's format. At least for now, dates must be entered as mm/dd/yyyy.

[armstrongcyber]

Ah cool, but the problem is that the mask you suggest is not accepted by the app.

So I have to select 9th Feb in the data picker to get 2nd Sept in the system. The screenshots above are for the same value entered in the GUI and then displayed back at the user.

[chrismaddalena]

I'm unable to reproduce this right now, but that seems weird. I wonder if it might be related to the locale of the system running Django. I will look into it.

[spankywetfish]

I've just had the same issue in the server checkout page, used the datepicker to choose 23rg August 2019 as the end date, it populated the field as 09/23/2019 and said the date was invalid when i tried to save.
Swapping the populated field to the dd/mm/yyyy format allowed saving and the page correctly displayed the dates afterwards, so it's likely just a failure of the date validation.

[DemanNL]

Can confirm this issue still exists. And have included an untested fix at the end of this post.

OS: Windows 10 Pro
OS timezone: Europe/Amsterdam

Ghostwriter base.py timezone settings: UTC

Using the date-picker, selecting 7 april 2020 and 9 april 2020 results in 4 july and 4 september, after saving the changes.
The date shown in the input box is 04/07/2020 and 04/09/2020.

Entering 07/04/2020 in the input box, ignoring the misleading date picker changes the date to 7 april, after saving the changes.

Now I tried changing timezone settings in base.py to: Europe/Amsterdam.
Sadly it didn't have any affect and the issue still persists.

Also the locale folder in /app/locale is empty. I assume this folder should contain locale info for proper date and time settings?

I have resolved the issue performing the following steps:
Open a bash shell on ghostwriter_django_1
Edit the following file: /app/config/settings/base.py
Set USE_L10N to False

The date-picker now properly works. I have yet to test further functions to see if this effects anything else.

[chrismaddalena]

It looks like the above solution is at least one option for avoiding locale and timezone issues. Both USE_L10N and USE_I18N affect how dates are interpreted and displayed. Django docs mention:

Note that if USE_L10N is set to True, then the locale-dictated format has higher precedence and will be applied instead.

https://docs.djangoproject.com/en/3.0/ref/settings/#std:setting-USE_L10N

There is a setting in base.py for locale paths, as specified here:

https://docs.djangoproject.com/en/dev/ref/settings/#locale-paths

Setting USE_L10N to False should have no negative effects on Ghostwriter. The default time zone for everything is UTC anyway.