Solved

Date headaches

Forum|Forum|11 months ago
August 8, 2025
19 replies
0 views

I've been having headaches with dates in Appian and I think it has to do with the way appian handles timezones.

Unless I'm mistaken, appian is supposed to record dates in GMT then then later read them in whatever local time zone is appropriate. What I'm finding is that it records in the local time zone, then later reads it as though it were GMT and adjusts to the local time zone, resulting in incorrect dates.

The more frustrating thing about this is how I access/display the date affects what gets shown.

For example if I use a date picker, appian records the date as 4 hours earlier. Thus 8/8/2025 will be recorded in the db as 8/7/2025 8:00 pm EDT

If I display the date in a text field, I'll get 8/7/2025 8:00 pm EDT, but if I put it through any kind of function such as text() to format what it looks like it'll come out as 8/8/2025.

What's worse is I imported a csv of a bunch of legacy data and the dates were all converted to date/time and had the 4 hours subtracted when recorded.

How can I keep this from happening?

Best answer by mikes0011

The functions local() and gmt() are your friends. It's tricky to remember how and when you can/want/need to use each, but with practice you will get used to it.

shubhama926776

You're using DateTime instead of Date type. DateTime gets timezone-converted (causing your 4-hour shift), but Date doesn't. Switch your CDT fields from DateTime to Date type and use a!dateField() instead of a!dateTimeField().
For existing data, display with text(gmt(ri!dateTimeValue), "MM/dd/yyyy") to bypass timezone conversion. For CSV imports, use todate() not todatetime().

harshas2775

In your process model , that writes record to this table , can you check the time zone is GMT in the process properties-> time zone . Also confirm that the checkbox ‘Override with initiators time zone’ is unchecked. If its checked then the data will be stored as per the process initiator’s time zone setting instead of GMT so you should have it unchecked! Let me know how it goes.

stefanhelzle0001

https://appian.rocks/2023/02/13/working-with-time-in-appian/

M

marcot345826Author

I actually read through that before posting, but my problem here is that no matter how I adjust the time, it records as EDT/EST, even if the time is inaccurate. If I use a date picker, it will translate that to local time, making it a day earlier, and even if I use GMT() to translate it to the right date, the timezone it records is still EDT/EST. I want the time zone tag to be correct for the time I'm recording and it seems bizarre to me that these time zone adjustment functions like local() and gmt() don't allow you to set the time zone, just add/subtract time.

stefanhelzle0001

Do you use the Appian cloud database? If not, did you make sure that your DB server runs in GMT?

Appian treats dates/datetimes only in GMT! Internally! As soon as such a value becomes visible, it is translated into the users timezone.

It is simple, but you can build yourself a ugly trap once you try to translate dates yourself.

mikes0011Answer

Brainy

The functions local() and gmt() are your friends. It's tricky to remember how and when you can/want/need to use each, but with practice you will get used to it.

M

marcot345826Author

The thing is they don't change the time zone, just the time, which makes things sticky. Say it's 4:00 now. I use the now() function and appian returns 4pm EDT. If I use the local() function, it gives me 12pm EDT. wrapping now() in the GMT function gives me 8pm EDT. They all say EDT regardless of the actual time zone that is being recorded. I want the time zone in the db to at least be accurate

mikes0011

Brainy

You have to remember that some date/timestamps are stamped with a timezone and some are not. A lot of the confusion comes into play when dealing with an inherently non-timezone-stamped time value (like "today()") but then dealing with that in the context of a time rather than as a date, when it inherently gets timestamped - and, of course, Appian treats all timestamps behind-the-scenes as GMT/UST, other than how they're displayed to the end user - this is where things like GMT and LOCAL come into play.

I want the time zone in the db to at least be accurate

The "time zone in the db" is always accurate, as it's always GMT/UST. What you must straighten out is what the end user sees and what gets saved/retrieved, and often, this goes hand-in-hand with the developer's understanding thereof.