Bug datepicker with format changed

[iNeoO]

Is this a BUG REPORT or FEATURE REQUEST?:

• BUG
• FEATURE

What happened:
When changing date format, date picker bug

What did you expect to happen:
get the good date in date picker

How to reproduce it (as minimally and precisely as possible):
in settings change date format
go to date picker in the edit ticket form

Anything else we need to know?:
settings

Gif of the bug

Environment:

• Trudesk Version: 299edb4 : 1.0.15
• OS (e.g. from /etc/os-release): ubuntu 18.04.2 LTS (Bionic Beaver)
• Node.JS Version: 6.7.0
• MongoDB Version: v3.6.12
• Is this hosted on cloud.trudesk.io: no

[polonel]

Are you referring to the rendering issue where the date renders the default format and then quickly switches to the customized format?

[iNeoO]

Nop, picking 4 January change the date to 1 may in the date picker

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[iNeoO]

Up

[jackd942]

I can confirm this on our end as well. Although in our case, the date that gets stored to mongo appears to be one day off...ie select 8/6/2019 saves 8/5/2019. UI for the date picker seems to have some strange behavior as well...if selecting 8/6, it re-renders to 8/5, but if you keep changing it, 8/6 will eventually stick, although 8/5 still gets sent to the db.

[polonel]

I store all dates in mongo as UTC so I can handle the time zone offset depending on user settings. This might be why you’re seeing them one day off. They get set back to +0

…

On Tue, Aug 6, 2019 at 12:12 PM Jack Davis ***@***.***> wrote: I can confirm this on our end as well. Although in our case, the date that gets stored to mongo appears to be one day off...ie select 8/6/2019 saves 8/5/2019. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#247?email_source=notifications&email_token=AAEY473YID5RDGYDMOPIR4DQDGPHHA5CNFSM4IEY4MRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VVEEI#issuecomment-518738449>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEY47ZQR2FQT3ENGQ76VQDQDGPHHANCNFSM4IEY4MRA> .

[jackd942]

Just double checked to make sure my Timezone was set correctly and it is. So I guess the logic in the component is not taking the timezone setting into account?

[polonel]

That may be the case. I’m going to dive deeper into it tonight

…

On Tue, Aug 6, 2019 at 12:34 PM Jack Davis ***@***.***> wrote: Just double checked to make sure my Timezone was set correctly and it is. So I guess the logic in the component is not taking the timezone setting into account? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#247?email_source=notifications&email_token=AAEY47YCFHVCGG5HINJWY2TQDGRZFA5CNFSM4IEY4MRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VXDVA#issuecomment-518746580>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEY4776UPMKDIME5JKZ3UDQDGRZFANCNFSM4IEY4MRA> .

[jackd942]

Actually I'm not sure if that is the case. We are -5 and still seeing the behavior I described above. It is currently 11:45am 8/6 here and utc is 4:45 8/6. We still see that behavior, so I think that may rule that out.

[polonel]

@iNeoO @jackd942
I pushed a fix (hopefully) to develop. If you guys don't mind giving it a test on your environments.

[iNeoO]

thx, that's fine for me ! (we can close)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.