date format when different than now

[leantalent]

Describe the bug

saving the date DotNetNuke.Services.Exceptions.ModuleLoadException: Conversion from string "10-15-2020 14:31 PM" to type 'Date' is not valid. ---> System.InvalidCastException: Conversion from string "10-15-2020 14:31 PM" to type 'Date' is not valid. at Microsoft.VisualBasic.CompilerServices.Conversions.ToDate(String Value) at DotNetNuke.Modules.Blog.PostEdit.cmdSave_Click(Object sender, EventArgs e) --- End of inner exception stack trace ---

Software Versions

• DNN: 09.08.00
• Module: 06.05.01

To Reproduce

Edit a post and choose a date where Date is >12. Looks like the date picker display the date in this format 10-15-2019 14:48 PM But is needed 15-10-2019 14:48 PM

In the Blog_Post table the format is 2020-10-15 12:31:00.000

Expected behavior

Date Picker has to use DD-MM-YYYY HH:MM A format

[coeamyd]

I am amazed, this bug has been around for almost a year now, and nobody even posted a reply to this. I have the same issue on a site, that is run only in German. The DNN version is 9.9.1, the Blog module version is 6.5.2.

My customer cannot use the publishing date feature, because we always get the exact error stated above (cannot parse date), because the server is running with a German locale, the UI however sends a (more or less) US style date. I have implemented a workaround for now by simply editing the PostEdit.ascx file and changing the flatpickr's dateFormat option to "d.m.Y H:i" instead of the default "m-d-Y H:i K" format.

Being a developer myself, I would suggest either supporting various locales using resources, which then change the format of the flatpickr, or, as a quick fix, change the date parsing on the server side to accept the specific format sent by the widget.

Frankly, this should be very easy to fix, and I wonder why nobody else has complained about it yet. I will see, if I can provide a pull request for this.

Cheers, Christoph

[coeamyd]

Sadly, I'm a C# developer. I have found the offending line in PostEdit.ascx.vb line 256. My guess is the CDate just tries to parse the date in the format of CultureInfo.CurrentUICulture. In C#, I would replace this with

DateTime.ParseExact(PortalSecurity.Instance.InputFilter(dpPostDate.Text.Trim(), PortalSecurity.FilterFlag.NoMarkup), "MM-dd-yyyy HH:mm tt")

as a quick fix. The date will still be in US-ish format, but at least it will be parsed correctly by the server.

[leantalent]

@coeamyd thank you! I hope the developer will take care with a proper solution.

[WillStrohl]

I haven't dug into the source of this module for a while, but we should be saving dates/times in UTC and using the built-in .NET conversion to and from. Is the module doing something different in this case?

[WillStrohl]

Also, I think I'm the one that added flatpickr a while back when we launched the new official DNN community website. If I am indeed remembering correctly, I think I had said at the time that the front-end localization was tricky and we didn't have time to fix it before the PR was needed. So it was a known bug to begin with.

[coeamyd]

It is using CDate(...) to convert the date string. And this uses the server's CultureInfo, which in my case is German. However, the UI widget has a fixed US-ish format, which is not compatible with German. Therefore, the conversion throws an exception.

[coeamyd]

Yeah, I can confirm that front-end localization will not be easy, since someone would need to provide the format strings for every supported locale for flatpickr. That's why I'm suggesting to parse the date in the format specified for the UI, which is what my code above would do. I think, users can live with the format being US on the editing UI. But not being able to schedule publishing when not using en-US is kind of a no go :-)

[fkw]

Same problem for me, with french only website. An easy fix is to modify PostEdit.ascx

$(".bDatePickerTextBox").flatpickr({
       enableTime: true,
       dateFormat: "m-d-Y H:i K"
   });

where "m-d-Y H:i K" needs to be "d-m-Y H:i K"