Hello, I’m having a problem with dates in my flow
I have a daily item creation routine that always considers the current date, but the date is always displayed as the previous day in the item view and the current day in the table view. Here are some examples:
I checked the records today and there were changes to the problem
the records created today on 11/18/2024 using the current date
and being filtered to display only the 18th
now also display the date of the 17th in the table view
as well as in the record view
Good afternoon, could you please provide a forecast for analyzing this problem?
Due to the discrepancy between the date displayed on the tape and the date defined by the automation, we are having an impact on the kickoff of an important project.
@joao.matheus
What timezone are you in? if you are adding a date via an automation are you using your Timezone?
1 Like
Good morning, thank you very much for your help
I am using UTC 03:00
Using a calculation to return the datetime of the Closing Date is giving me 21:00 of the previous day, which is eight hours more than my creation date
Hi @joao.matheus,
thanks for your report. In order to look into this and find a solution, we’d need a little more info.
-
Field Type - What field type are you using for your field “Data do Fechamento”? Are you using a single date field? Can you share the full configuration of the field, in the “Edit fields” settings? If you are using a date field, is there a specific reason you are not using a “Created on” field, that will set and reflect the creation date for you automatically?
-
Timezone - Based on your location (Brazil), I would assume you are not on “UTC 03:00” but rather on UTC -3, is that correct?
-
Occurrence - When has that issue come up? Has this been working in the past and broke along the way, or has it never worked properly? That would help us with tracing down a potential root cause on our end.
Looking forward to your feedback and more info.
Cheers
Tim
Field Type -
We are using a date field because in the event of some instability or for some reason the flow does not run on that day we can perform retroactive creation.
Time zone - correct is UTC -3 I ended up typing it incorrectly, I apologize
Occurrence - started happening around the bug opening date
this process was started a few weeks before that and in its first few days it was working correctly
1 Like
Thank you, that helps.
One follow up question: In your original report, you stated a discrepancy between the displayed day in the table, and in the record view. In your example, which one was displaying the correct result? The table or the record?
Cheers
Tim
the correct result was being displayed in the table
1 Like
Thanks - let me get back to you soon.
EDIT: We can confirm that there is an issue on our end. Fix incoming - thanks for your patience.
@joao.matheus we rolled out a fix this morning 
Could you check on your end whether your issues are resolved (after refreshing the Tape web app / reloading the window)?
Cheers
Tim
Hello, thank you very much, the main problem has been solved but when I call the date in a calculation it continues to be displayed incorrectly, see the example in the image
1 Like
Glad to hear the date display issue is fixed - thanks for your patience and for being persistent. That was actually a regression from our side after we had rolled out a few significant performance improvements (you might have noticed some apps loading faster than before).
Regarding the calculation question: That is the expected behavior. Calculation fields do not respect time zones and will always interpret inputs as UTC. Try to use the date_fns_tz library, as stated here:
You can try something like this:
date_fns_tz.zonedTimeToUtc(your_date, 'America/Sao_Paolo')
or
date_fns_tz.utcToZonedTime(your_date, 'America/Sao_Paolo')
You can then / also try to extract the calendar day. It depends on what you want to achieve.
Happy building
Tim
1 Like
Regarding the calculated field, I understand that it always brings the standard UTC, but the difference between the date displayed on the screen and the date of the calculated field is 8 hours. Is this correct even considering that we are in UTC -3?
@Tim I did some tests and even adjusting the date the UTC remains incorrect, displaying 8 hours. Here are examples of the tape and the calculated field
The client signaled to me that this is happening in other applications in the environment
Is this as you would expect:
if so it was achieved with this calculation field:
const la = date_fns.format(date_fns_tz.utcToZonedTime(@Date field, 'America/Los_Angeles'), 'yyyy-MM-dd HH:mm');
const uk = date_fns.format(date_fns_tz.utcToZonedTime(@Date field, 'Europe/London'), 'yyyy-MM-dd HH:mm');
const munich = date_fns.format(date_fns_tz.utcToZonedTime(@Date field, 'Europe/Berlin'), 'yyyy-MM-dd HH:mm');
const sao_Paulo = date_fns.format(date_fns_tz.utcToZonedTime(@Date field, 'America/Sao_Paulo'), 'yyyy-MM-dd HH:mm');
`
UTC = ${@Date field}
UK = ${uk}
Germany = ${munich}
Sao Paulo = ${sao_Paulo}
LA = ${la}
`
Thank you very much for your help, here is an example referencing the Closing Date field that uses the current date action in the automation
in this case I believe that the reference to SĂŁo Paulo should be bringing 5 am
I think I understand now the automation is failing to set the time on the date field which may be a bug (or me doing something daft as it’s late) as I couldn’t get it to work either even if I used the set time option however this does work:
Thanks for your help, today I’m going to test this path to speed up the correction
in the meantime, could you take a look at this new information @Tim ?
Hi @joao.matheus,
we have already prioritized the issue and will get back to you as soon as we have the first findings. Thanks again for the report and the great support from @Jason.
Best
Leo
1 Like