So, why would Totext() return a quarter before real value, when apply to Time field?

Suggestion Box Bugs
1

No much more to tell.
You write down your flamant 11:00 meeting in a Time field.
When you show it with your field.Totext(), it reads 9:45. Hurray! never late again :stuck_out_tongue:

PS: I am GMT+2, don’t think related

Edit 1: after @joost_mineur help, i have realized it has nothing to do with Totext, but somehow value shown through formulas differ a quarter from the value I entered, or that it’s shown in table cells.

Edit 2: An image worths more than thousand words

Paranormal time
Paranormal time1711×630 51.5 KB

2

Can’t reproduce that in my doc:

image

3

It only happens when value stored in table.

Actually, I have investigated more and discovered it is not related with Totext, at all.

I have added a second time field, was just playing with format (sure it wasn’t the cause but hey…)

I’ve discovered that, when I reference the field Time in the second field, the inspector reads its value as 10:45, despite the fact that I entered 11:00 and that it is also the value shown. Then, once formula accepted, this second time field also shows 11:00, but when you inspect the formula, the predicted value for the row is 10:45

4

Maybe some weird time zone bug? What time zone the doc is in?

I had a similar issue with Shanghai time zone.

GMT+2 could also have some quirks about some timezones, e.g. some municipality could have their times shifted 15 minutes off historically in the 1900s.

5

Hi @Paul_Danyliuk , an honor to have you here in my alt account hosted bug party…

Funny enough, i tried to report this and i found yet another bug :sweat_smile:, with the bug form

Anyway, I added my GMT(+2) because i thought it could be related, despite being a long, long shot. I use Madrid hour, like most Europe… we are exact +2:00 hours, always have been, but who knows…

If you, my friend, also don’t know why, I thought time had come to reach support. Lets see what they say…

6

I did know why though :stuck_out_tongue: Told ya, check your time zones

image
image1192×445 23.8 KB

image
image1207×357 18 KB

There’s a bunch of CESTs, and for a reason. Some regions historically had different time offsets. One of my clients had this issue with Asia/Shanghai vs Asia/Taipei (both China time but the latter was 15 minutes off), so I immediately assumes the same here.

CC @Matthew_Tebbs

7

You where right, but this raises two important questions,

  1. Why would formula editor evaluate to different value than the stored one, furthermore taking into account that value has been stored with the exact same regional configuration that is selected at the evaluation time?

  2. Why they set CEST/Madrid a quarter different from the official CEST? There is no such “historically different offset”, I guess its a mistake when they configured CEST/Madrid?

I.E, when you compare with Amsterdam in your example, in reality Madrid has the exact same regional time configuration than Amsterdam, it shouldn’t evaluate different both examples

8

There’s two things you need to know:

  • Coda tracks time relative to 1/1/1900 for some reason. This is unconventional but I cannot say if it’s a bug or a design choice I can’t yet see the reason of. The result is that 11 AM is basically 11 AM 1/1/1900 or something.

  • Coda did not program timezones — IANA did. Coda just took an existing library. The problem with IANA though is that it only reliably tracks historical time changes since sometime 1900, and apparently before 1900 there were all sorts of weird regional offsets.

This here says that before Jan 1 1901, Spain GMT offset was -0:14:44:

Then there was some royal decree that standardized times starting from 1901:

That’s basically the story there. Working with date/time and timezones has been the biggest PITA for software developers ever since, particularly because of all these quirks. While it is strange that Coda decided to base their dates on 1900 and not 1970 like it’s universally done (and would’ve probably avoided this) I believe they had their reasons, as I learned over time that they’ve usually had.

4 Likes
9

Holly cow!

You are right!
And incredibly good research skills with our public digitalized bulletins.

I will mark yours as answer, since its an answer about what it is happening here

I would add that full explanation seems to be that CODA flags data as CEST + 2:00 when stores value, and when renders fields value, but apply CEST +1:45 when the value is transformed to text.

So as far as you are not manipulating times as text (rendering them as text), everything should be fine