Hi, I found that Now() does not return the real current time when used in API:
Let’s define a button column in a table, the button will set the value of a column X to Now() when pressed.
If the button is invoked manually, everything works and X and native column “Modified on()” have the same value.
Instead, if the button is invoked by an API call, the value put in X is several seconds before current time, and infact “Modified on()” is up to 50 secs - 1 minute later than X, and “Modified on” holds the correct time when X was modified.
I found that in the latter case, the value returned by Now() seems to be the latest timestamp Coda has in its cache, is infact the (previous) value of “Modified on”.
This behavior in API usage seems to be quite a problem, since there is no way to actually precisely track when an action has been done through the API…
Any thoughts on this?
thanks
Hi @Giuseppe_Covino - Thanks for the detailed bug report! I’ve been able to replicate this behavior, and it is quite odd. I’ll follow up with the team to see if there is anything we can do to fix it.
1 Like
Thanks Eric for the feedback
Hi @Eric_Koleda , any news from the team?
thanks
Hi!
@Eric_Koleda and @Giuseppe_Covino, we have the same issue, with much greater differences.
We also use the API to insert e.g. Home Office Tracking via an API.
And it looks the same, Now() seems to be cached.
We call the API at fixed times (full hour), but sometimes Now() inserts the time from the last insert as it seems, and or the last time the doc has been viewed?
The “Created On” column always seems to be correct.
Left Column = Now(), right Column = Created On (calculated property).
From the Coda API Documentation:
Volatile Formulas
Coda exposes a number of “volatile” formulas, as as Today(), Now(), and User(). When used in a live Coda doc, these formulas affect what’s visible in realtime, tailored to the current user.
Such formulas behave differently with the API. Time-based values may only be current to the last edit made to the doc. User-based values may be blank or invalid.
So Now() is only ‘valid’ when viewing your document in the browser.
To get a reliable timestamp value during server-side executions you will need to create your own formula using a pack.
From the Coda Pack SDK Documentation…
Timezones in Coda¶
Every Coda document has a Timezone setting in the Region section of the settings menu, that defaults to the timezone of the device that created it. All dates and times entered in the document are interpreted in the context of that timezone. Users often don’t need to be aware this, since all of their interactions with the dates and times take place in the context of that doc.
Packs don’t have a configurable timezone however, and all date and time operations in Pack code run in Coordinated Universal Time (UTC). The timezone of the document is passed to Pack formulas as context.timezone, containing an IANA timezone identifier (ex: America/New_York).
Working with timezones¶
Because of timezone shifting you often can’t use the Date objects in Packs like you would in other environments. Getter methods like getHour() or getDate() will return those values in a UTC context, which may be different than what the user has entered. Likewise setter methods like setHour() or setDate() won’t work correctly, as they aren’t aware of the daylight savings time rules in the document’s timezone.
Unfortunately JavaScript’s native Date class doesn’t provide the ability to easily work with dates across timezones. For instance, you can’t change the timezone of a Date object or pass a timezone to methods like getHours(). Listed below are some approaches to deal with this limitation.
So you can create a Pack Formula to return the current time using the javascript Date object, but it will return the time in the UTC time zone.
You will need to use the time zone context variable to adjust from UTC to the document’s time zone.
Respect
Max
2 Likes
Thanks Max, interesting reading.
It fascinates me how “simple” topics quite often are really complicated under the hood. Add in the Julian vs Gregorian calendar, and the fact that the switch was made at different times in different regions. Even different states/colonies at different times in the US.
But it’s just a ramble….
yrue.
here in Greece they have not yet fully adopted the Gregorean calendar.
the Julian system still determines religious feast days like xmas and easter etc.
their attitude is that this new fangled Gregorean calendar system frome rome is very new and unproven.
WOW!!
I was aware that Easter falls on different days for the Eastern Orthodox church, but wasn’t aware that is the reason!!
In the Western churches we go by the cycles of the moon, in some complicated fashion.
Funny enough, I mentioned your post to our “Network Security Guy” in the context of an easy vs complex dicsussion. He immediately pulled up a Json code snippet that he has to maintain to get around date problems for our company.
P
