TextToDateTime behaviour changed from 9.0 to 9.1?

TextToDateTime behaviour changed from 9.0 to 9.1?

  

Hi,

We are moving from an environment running OutSystems 9.0 to 9.1.

In the old environment, the TextToDateTime function was converting Australian dates correctly (ie, TextToDateTime("06/08/2016 00:00:01")).

However in our new environment this conversion becomes the NullDate() value 1900-01-01 00:00:00.

The documentation states that it will use the Environment's Date Format for the conversion, however in both environments this is set to YYYY-MM-DD.

I've attached a screenshot showing the information above in both environments.

I'm wondering if the implementation of the TextToDateTime function has changed, or if there's something else I'm missing? And what would be the best way to perform this conversion?

Thanks,

John

Hi John,

There appears to be no change in that function. Have you checked the date format that is set in ServiceCenter? Is it the Australian format?

Hi Carlos,

The Date Format in ServiceCentre is the same in both environments (YYYY-MM-DD - see screenshot attached above) and yet the TextToDateTime function works in one and not the other. Is there anything else I should check?

Could it be due to the fact that the 9.0 environment is on a J2EE server and the 9.1 environment is on a .NET server?


Carlos Xavier wrote:

Hi John,

There appears to be no change in that function. Have you checked the date format that is set in ServiceCenter? Is it the Australian format?



Hi John,


I just compared both implementations and didn't see any relevant difference.

Can you do call a DateTimeToText function in your 9.0 environment to see how it gets formatted?

Also are you using the same browser/pc/application to test it? (ex: having a windows 10 can change the browser inputs behavior and it displays a different value than it is actually there)


With that Service Center configuration the parsing of that format should not be working in either environment.

Regards,
João Rosado

Forgot to ask what is the stack: .Net or Java?

Hi João,

The 9.0 environment is running on Java and 9.1 is running on .NET, could that cause the difference in behaviour?

I ran DateToText on both and as expected they both returned the date as 2016-08-06.


João Rosado wrote:

Forgot to ask what is the stack: .Net or Java?



Solution

Yes that explains the difference.

I was able to track the cause of it ...but the correct behavior is actually the .NET (it should not be able to parse). 

The reason is that both MM-DD-YYYY and DD-MM-YYYY are both valid and used formats but they cannot be distinguished. So none of the functions should try to parse them by default as they can lead to data corruption.


If you want to be able to parse them in inputs you will have to change the date format configuration in service center, but that will also have more side effects (like the change in the DateTimeToText usages).


Note: the TextToDateTime is always able to parse YYYY-MM-DD formats regardless of the configuration. That is not mentioned in the documentation, but it is also by design to improve compatibility with the DateTIme ISO format and since there is never a format that conflicts with it.


Solution

That makes sense, thanks very much.

João Rosado wrote:

Yes that explains the difference.

I was able to track the cause of it ...but the correct behavior is actually the .NET (it should not be able to parse). 

The reason is that both MM-DD-YYYY and DD-MM-YYYY are both valid and used formats but they cannot be distinguished. So none of the functions should try to parse them by default as they can lead to data corruption.


If you want to be able to parse them in inputs you will have to change the date format configuration in service center, but that will also have more side effects (like the change in the DateTimeToText usages).


Note: the TextToDateTime is always able to parse YYYY-MM-DD formats regardless of the configuration. That is not mentioned in the documentation, but it is also by design to improve compatibility with the DateTIme ISO format and since there is never a format that conflicts with it.