Question

Localization DateAndTime Variable

2

There is different behaviour in the following situation: Calculate DateAndTime field in a Non persistant entity (Localize=No) Create DateAndTime variable In both situations the value is calculated as follows: parseDateTimeUTC(<stringvalue>, 'yyyy-MM-dd''T''HH:mm''Z''') In case 1, the value is as I would expect it (Date and time is exactly the same as the string value), but in case 2 it is localized. Is there a way to create a non-localized dateAndTime variable ?

asked 2013-04-02

Barry Ludwig

4 answers

Ronald Catersels · Answer 1 · 2013-04-02

In case 2 the object is in UTC (see for yourself when you open the postgres database if you store it there. But dependent on your model settings the variable will show the localized time when running the model and set a breakpoint. But it will store the UTC date in the database if the entity is set with localize off.

Regards,

Ronald

Erwin 't Hoen · Answer 2 · 2013-04-02

Barry,

If I understand correctly the time you get as an input is already in the timezone that you want to display it in. So if the time you get is 01-01-2013 10:00 this should remain the same when displaying it to your user or when creating a variable independent of the timezone of the user? Then just display it in a field with the localization set to No, as you state this already works. When creating the variable from the string this variable will be in UTC, look at the debugger to see the value. Now to add the one day you are mentioning you can used AddDaysUTC(parseDateTimeUTC(<string>, <your format="">), 1) this will remain to be the date entered with 1 day added. So the variable mentioned before will become 01-02-2013 10:00. As said the date is stored in UTC in the DB it is only the client that will localize the date when the attribute is set to do so, so the calculations should not pose any issues but keep in mind that you need to set fields to localize no and use the UTC functions.

Barry Ludwig · Answer 3 · 2013-04-02

Thanks Ronald,

The problem is not in the DB (DB is correct), but in calculations. In case 2, we don't have the possibility of localization because it is a variable.

If we would like to calculate an arrival date as 'startdate+1 day at 10:00', it should not change anything based on the user, because arrival will can be in any timezone (which cannot be determined) and it is already in 'local time' of destination. I would like to just store the 10:00 without depending on a user/server setting.

Basically what I would like to store all dates 'as-is' without any 'conversions'.

Regards Barry

Barry Ludwig · Answer 4 · 2013-04-03

I think I found the 'problem'

If attributes are displayed in form, they are correct (No localization), but when these datetime attributes are displayed using a 'show message' they are localized ?