Date format changes when the date is entered in the input field

[duvel3]

Bug reports must include:

Windows 10 19044.1586 Microsoft Edge 100.0.1185.29 (Official build) (64-bit) tempus-dominus 6.0.0-beta5

When the date is entered by hand (so when you not use the date picker) then the month/day gets swapped each time the entered date exists (so 04/12 will be swapped to 12/05 instead of 05/12, but 13/12 will correctly be formatted to 14/12). I can reproduce the issue with all datepicker examples on your site except the Linked pickers, which doesn't swap.

As seen on the image below, I only changed the day (04 to 05 to 06), but the datetime picker swaps the day and month on each edit. This issue does only occurs when the date is manually edited in the field.

[eryx12o45]

I have exactly the same problem, as I want to display dates which come from the db, I've tried to do so by using the "defaultDate" param, unfortunately this doesn't fill in the date into the input field anymore, therefore I tried filling in the input field's "value" param with the database value "manually" which results in exactly the same behaviour as mentioned above.

Mac OS 12.3.1 Google Chrome Version 100.0.4896.127 (Offizieller Build) (arm64) tempus-dominus 6.0.0-beta5.1

[JerryBels]

I have the same problem with some dates that gets to the input already formatted, like 09/05/2022 for May 9th and it gets swapped to 05/09/2022. Came here to look for a solution, and indeed, that's an incredibly annoying bug, you CAN'T enter a date by hand as it will get swapped immediately!

I think this should be considered critical, tbh, as a basic behavior (entering by hand, or copy-pasting something like 09/05/2022) simply won't work!

I mean, go click today's date, click out. Come back in, add a space, click out - it switched. And you can do it again, and again, and again.... It's kinda addictive but it misses the point, right?

[Eonasdan]

I do not experience this issue. What's your browser's locale? You can find this easily by going to this stackblitz

[duvel3]

@Eonasdan My locale is en-GB, but I don't have this issue on my other pc with locale 'nl'. On both browsers I get this problem with the Russian locale example on your site.

[JerryBels]

Your browser's locale is "fr-FR"

I can confirm that if I simply add a space on the stackblitz it switches day and month.

[DragosChirila]

Hey,

I have a similar problem.

Because my browser's locale is en-US, I am setting up the picker like this:

	$(function () {
		new tempusDominus.TempusDominus(
			document.getElementById('tempus_dominus_id'),
			{
				localization: {
					locale: 'en-GB'
				},
			}
		);
	});

What happens is:

• first time I am loading the page I see this: 11/05/2022, 7:14 am
• if I just hit F5 to refresh the page without changing anything in the input field, the content changes to 05/11/2022, 7:14 am
• same issue if I submit the form and go server side (FYI the server is Django and it is configured with LANGUAGE_CODE = 'en-gb' and TIME_ZONE = 'Australia/Melbourne')

Am I missing something here? Thanks

[Konstanty]

Same issue for 10 MAY -> 12 MAY for myself too. Locale is en-AU on the browser.

[Eonasdan]

The issue here is that the native javascript date object is dumb and extremely limited. If you did new Date('12/04/2022') in the console you would see that get translated to "Sun Dec 04 2022 00:00:00".

I choose not to force an external date library (dayjs/moment/etc.) to avoid the extra dependencies and to make it easy to go from 4/5 => v6. The problem is that my date extension is not as robust as one of those libraries.

I see three solutions to this:

1. Overwrite the dates.parseInput. You can either parser the input yourself or use a date lib to work this out. I recommend doing this for the time being.
2. I can extend the localization files to include format patterns similar to this.
3. Require a date library as a dependency.

It's easy for me to recommend (1) because it doesn't add any work for me 😁 .

I'm leaning towards (2). This means that I also have to make sure the picker is able to parse those formats.

[Eonasdan]

Please take a look at this. I found some code that tries to guess the locales default format. Let me know your results.

[JerryBels]

Hey, thanks :) I will try it next week somehow. And yes I agree, (2) is the best option. Or at least document the issue in the docs and give examples on how to resolve it with (1).

[Eonasdan]

You can look at the plugin docs here for an example of the overwriting a function.

[duvel3]

Hey @Eonasdan the fix with the momentjs plugin solved the problem, but we have the problem that we uses multiple configurations (datepickers with and without seconds for example), but this fix will parse all with/without seconds. So I tried the Per Picker fix, but this won't work for me, the formatInput won't format it correctly for me, while the setFromInput will give me a "value provided is not in a recognized RFC2822 or ISO format" exception.

The strangest thing is that I use the 'nl' locale in the datetime picker setup with: tempusDominus.loadLocale(tempusDominus.locales.nl); tempusDominus.locale(tempusDominus.locales.nl.name);

When I use a en-GB browser it won't format it correctly but with a 'nl' browser it will parse the dates correctly. I think option 2 would be the best for all people who want to use your library.

[Eonasdan]

@duvel3 you don't have to use moment btw, you can use dayjs or whatever. If you aren't using moment for anything else, I'd highly recommend you use dayjs instead.

You can use the plugin as an example for how you could make this work. If you took the parsing bits outside of the plugin you could do what you needed per picker. There's also a meta property on the options object that you can add any property you want. So you could add your per picker format there and then in your parser, grab this property to format the date.

Please take a look at this. I am trying to figure out if this code is smart enough to properly figure out a format string.

[fgiamma]

Hello @Eonasdan, having the same issue I tried to follow various suggestions but I can't still figure out how to solve the problem.

My browser in in English, but I need to have the date in Italian for my customers. I set the date in the picker configuration:

`var itLocale = { today: "Oggi", clear: "Pulisci", close: "Chiudi", selectMonth: "Seleziona mese", previousMonth: "Mese precedente", nextMonth: "Mese successivo", selectYear: "Seleziona anno", previousYear: "Anno precedente", nextYear: "Anno successivo", selectDecade: "Seleziona decade", previousDecade: "Decade precedente", nextDecade: "Decade successiva", previousCentury: "Secolo precedente", nextCentury: "Secolo successivo", pickHour: "Seleziona ora", incrementHour: "Incrementa ora", decrementHour: "Decrementa ora", pickMinute: "Seleziona minuto", incrementMinute: "Incrementa minuto", decrementMinute: "Decrementa minuto", pickSecond: "Seleziona secondo", incrementSecond: "Incrementa secondo", decrementSecond: "Decrementa secondo", toggleMeridiem: "Imposta pomeriggio", selectTime: "Seleziona ora", selectDate: "seleziona data", dayViewHeaderFormat: "long", locale: "it-IT", startOfTheWeek: 1 };

    var picker = new tempusDominus.TempusDominus(document.getElementById('datetimepicker1'), {
        display: {
            viewMode: 'calendar',
            components: {
                useTwentyfourHour: true,
                decades: true,
                year: true,
                month: true,
                date: true,
                hours: true,
                minutes: true,
                seconds: false,
            }
        },
        localization: itLocale,
        defaultDate: today,
        localization: itLocale
    });

`

Everything in the picker is in Italian and as long as I select the date via the picker everything works. When I manually input a date in the input field, it gets reversed in "MM/DD/YYYY".

I then overrided the formatInput function with moment: picker.dates.formatInput = function(date) { { console.log("d1: ", date); return moment(date).format('DD/MM/YYYY hh:mm') } } but when I select the date via the picker date "date" field in this function is in correct, for example for today I get in the log: d1: Date Tue Jun 07 2022 13:30:06 GMT+0200 (Central European Summer Time)

while manually inserting the date in "DD/MM/YYYY" format in the input field results in a date object in this function that is already wrong, for example if I change the date and insert tomorrow, I get: d1: Date Sat Aug 06 2022 01:30:00 GMT+0200 (Central European Summer Time)

Being the date object already swapped the format function can't solve the problem. If the day is under 12 it formats the date in the wrong way, otherwise it gives an error. Because the date gets here already swapped as a Datetime object I guess there is some sort of conversion before this formatInput method gets activated.

I am attaching three screenshots to show you the sequence. In the first one I selected the date via the picker, in the second one I manually change the day and it shows just before I exit the field. The third one is what happens as soon as the field losts focus and the inputFormat gets activated.

Am I missing something? There should be something I didn't understand of the whole process.

.

[Eonasdan]

What I need people to do is take a look at this. I am trying to figure out if this code is smart enough to properly figure out a format string.

I added a textbox to make it easier to change what locale the code uses.

[JerryBels]

Looks good, I'd say

[Eonasdan]

Please test this out

Please go to this stackblitz and try a couple of date/times and formats. I've borrowed a bunch of code from a dayjs plugin that allows you to provide a string date and a string (or array) of formats. The localization object will be updated with some defaults.

I don't know if I will use the guessing code from before or not.

If a couple of you can verify what this code does, I'll either add it directly the the DateTime object or it will be a plugin.

[JerryBels]

Okay, I tested a bunch of dates in my french browser. All good with the format provided. I think the best would be adding guess capabilities but allow for a format to be submitted as well to force the issue. Great work!

[Eonasdan]

Thanks for helping me test this @JerryBels

How about it @duvel3 @eryx12o45 @DragosChirila @Konstanty @fgiamma ?

[rmaspero]

I agree with @JerryBels that being able to provide a format to force the issue would be useful.

[Eonasdan]

Hello @JerryBels, @duvel3 @eryx12o45 @DragosChirila @Konstanty @fgiamma, @rmaspero

I've created a branch to try and bring all this together. None en-US or ISO string formats will require a plugin.

Please check this stackblitz

[jcompagner]

hmm the picker will do its own formatting and parsing. We use already Luxon for that so i don't really need that this library also does its own thing again. So for me Point 1 would be fine, the only problem is that Point 1 must have a good implementation Which in the past we had (when it was config.hooks.parse/format) with the hooks it was a perfect setup for us without any problems what so ever. The problem started when it was not so obvious anymore what todo when the config.hooks where removed.

Overriding class functions is not ok, because formatting is a instance thing Overriding instance functions is also a problem because we are to late (we can only do this after construction but the constructor/init code can already hit parse code)

So for me, just bring back the hooks on the config (parse/format functions)., document that, and then it is very logical to use and no need to maintain any format/parse code what so ever in this component.

[Eonasdan]

@jcompagner if you look at the last comment of mine and the stackblitz I think you'll be interested in what I came up with.

Hooks are not coming back. There's easy ways to overwrite bits that don't work for you globally or per picker.

[jcompagner]

yeah i think that could also work for us, if we can overwrite it at class level but then get enough state through the config to do our own parsing at the instance.

So yes if we can set our format string in the config.localization and we can get that on the "this" again on in our format/parse functions then this could work but:

The problem i still have with overwriting classes is who will be able to do that, we have many packages that don't know each other and all of those packages could use in 1 form or the other a calendar. So who is going to overwrite it at the class level in this instance? is it Package 1? or is it Package 2?

What happens if i use another 3rd party thing that uses your component and does this overwrite? Then will be overwriting it again... or it depends who goes last..

So i still think i cant use this class level overwrite. i need it to be at the instance level. because i just can do this because i have no idea for which thing i would then also change it...

This override of classes is really a bad thing in some projects, that are really a lot of stand alone packages that don't know each other.. Right if you are in a small project and you dictated everything that it works fine. because there is only 1.. But for us that is just not the case

[JerryBels]

Sorry, was out in vacation... For me the last stackblitz seems to behave correctly.

[Eonasdan]

This is now in the v6 release. I need to write up examples and docs for the plugin.

[hieplq]

This is now in the v6 release. I need to write up examples and docs for the plugin.

clear button don't work with customDateFormat plugin, see example here https://stackblitz.com/edit/tempus-dominus-v6-simple-setup-import-hjto8w?file=index.js

reason by this logic

format(dateTime) {
        if (JSON.stringify(dateTime) === 'null')
            return 'Invalid Date';

[Eonasdan]

This is now in the v6 release. I need to write up examples and docs for the plugin.

clear button don't work with customDateFormat plugin, see example here https://stackblitz.com/edit/tempus-dominus-v6-simple-setup-import-hjto8w?file=index.js

reason by this logic

format(dateTime) {
        if (JSON.stringify(dateTime) === 'null')
            return 'Invalid Date';

Thanks I'll take a look

[hieplq]

This is now in the v6 release. I need to write up examples and docs for the plugin.

dates.parseInput isn't work with customDateFormat plugin

see https://stackblitz.com/edit/tempus-dominus-v6-simple-setup-import-hjto8w?file=index.js i add line datetimepicker1.dates.parseInput(new Date()); click change button get error this.errorMessages.customDateFormatError is not a function

[Eonasdan]

I have a fix in but another npm package randomly disappeared and now github won't build the project. I'll try to get some time to fix this.