Date Time in Alpha Version 8483

[RustyB]

Anyone notice this change of behavior in Alpha version 8483. I have a Cordova app. If I have a date time field, I can save the date and time in a field fine. The problem is when I sync (using MariaDB database). The date and time sync and appear fine on the server, but the field in the app now has the time cut off. See images below.

Before Sync:
001.jpg

After Sync:
002.jpg

[Pizzadude]

There have been changes....

https://download.alphasoftware.com/R...o_present.html

UX and Grid Components - Date Format property - Previously, the Date format property in UX and Grid properties was used to control how the user was expected to enter date/datetime values (and also to control how the Date Picker returned values if the format for the Date Picker had been set to <Default>). The default display format for date/datetime values was determined by the regional settings on the server.

Now, the Date Format property in UX/Grid properties controls both how the user is expected to enter date values, but also how data bound UX controls (including List and ViewBox controls) and Grid components will display date and datetime values.
An example of how this will work from now on is: if the regional settings on your server are configured to render dates in MM/dd/yyyy format (i.e. US format) and the Date format property in a UX component is set to dd.MM.yyyy then assuming the UX is data bound, any control that displays date or datetime values, will use the dd.MM.yyyy format (because that is the format that is set in the Date Formatproperty. In addition, List and ViewBox controls that display date or datetime values will use the dd.MM.yyyy format for the date part (again, because that is the setting for the Date Format property).
Previously, the data would have been displayed in MM/dd/yyyy format because that is the format of dates on the server.
NOTE: Previously, when a date or datetime field was added to a Grid component, a default Format display property was set to:
time("{grid.clientSideDateFormat} 0h:0m 0s am",<value>).

Therefore, the values displayed in the Grid were formatted as dd.MM.yyyy (because the Date Format property had been set to dd.MM.yyyy. However if the Display Format property was removed, the data in the Grid's date and datetime fields would use the MM/dd/yyyy format (if that was the server format)

As a result of this change, when you add a date or datetime field to a Grid, the Display Format property is no longer set (because it is not needed).
The benefit of this change in behavior is that it is now easier to create applications that deal with date and datetime values in a more intuitive manner.
For example, say you have an app that is hosted on Alpha Cloud. The server format for dates on Alpha Cloud is MM/dd/yyyy. This means that if a developer is hosting their app on Alpha Cloud, date and datetime value in the application would by default be displayed in MM/dd/yyyy format. Any user of this app who was outside the US would likely expect the date and datetime values to be formatted in dd/MM/yyyy format.
This is now easily achieved by setting the Date format property in the Grid or UX to <cultureDateFormat> (and if you also want to display dates with time values set the time part of the Date format to <cultureTimeFormat>).
When a user in (say) the UK accesses this app, dates will be displayed in dd/MM/yyyy format (because the browser will automatically tell the server what culture to use. Similarly when a user in the US access the same app, dates will be displayed in MM/dd/yyyy format (because that is the format for dates if the culture is US).
During development, the developer might want to know how dates will be rendered for users in any particular culture. If the Date Format is set to <cultureDateFormat>, a new property is displayed (Simulated culture). This allows you to simulate any culture.

[RustyB]

Yes, I noticed there were some changes. In my UX, I have the Date Format as MM/dd/yyyy. I've always left the Time Format blank, but perhaps I can try filling it in and see if that helps.

[Steve Workings]

I just upgraded to 8565 and am dealing with this for an app with a *lot* of date fields in it. Users immediately had problems entering a date value -- they kept getting the date/time values.

Setting the web projects property for Server Side Date Format for UX and Grid Components now appears to let the users correctly type in a date value. But the date picker is still returning the date and time values to the date field.

How to adjust the date picker to only return the date part? I want to return mm/dd/yyyy but can't find a property to do that.


Edit: After more work/time with users I can refine this: I'd like the date picker to only display and return the date part for a control that is date type.

[RustyB]

Setting the Date format in the Properties of the Date picker seems to work for me. I am on version 8483 though.
Capture2.png

[Steve Workings]

Rusty - I may try that, but was hoping for something that didn't require the editing and republishing of a large number of components.

[Pat Bremkamp]

Don't know who this change helped, but certainly not us. We have the same issue of over 600 components to change, an extremely time dependant application, 24 X 7 operation. The only thing that allows us to stay in business is to roll back to an earlier release. Wish Alpha would quit having these "hold my beer and watch this" ideas.

[peteconway]

IT'S SCARY REALLY. Would have been better as an opt in.

[Ted Giles]

I have been developing a DT app for a USA user.
In A5 V4, there is a setting to change the format and that foxed me as in V11, there is no such setting.
In the UK, dates are dd/mm/yyyy, so I changed my windows setting to get everything to work.
Al B pointed out that nowadays, windows sets the format.
This looks like a bit of a backward step from Alpha.

[peteconway]

Same with Language - Google has nailed that - language tags the same.

[Ted Giles]

Sausage fingers !
it was A4 V3 

[CharlesParker]

agreed the date format should just cut the time portion out if AS wants to change it fine but there should be a clear separation between the 3 choices regardless of what is on the back end meaning "date - time - date& time"

[CharlesParker]

Looks like this change is more about dealing with everyone across the globe rather than just a US thing which is probably good in many ways - seems like it could be better determined in the project properties rather than as a "from now on" change since so many previously built applications may be hindered to move to the next release.