EPOCHTODATE

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1655906710 with =EPOCHTODATE(A3,1) -> 6/22/2022 14:05:10. Independently recomputed as 1970-01-01T00:00:00Z + 1655906710 s = 2022-06-22T14:05:10Z. Asserted through TEXT with an explicit unambiguous pattern rather than against the page's US-format display string, so that a cell's number format cannot decide the case. The Note that makes UTC the right frame reads: "The result will be in UTC, not the local time zone of your spreadsheet." EPOCHTODATE's page carries a real Timestamp/Result/Formula table in the article body, so the five rows below are Google's own published outputs rather than derivations. Each was independently recomputed here from the Unix epoch in UTC before being written down, and all five reproduce. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1584033897 with =EPOCHTODATE(A5) -> 3/12/2020 17:24:57. Independently recomputed as 2020-03-12T17:24:57Z. This is the row that pins the default, and the Note agrees: "Seconds is the default unit of time." Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 0 with =EPOCHTODATE(A4,2) -> 1/1/1970 0:00:00. Asserted as a difference against DATE(1970,1,1) so that no date format enters the comparison. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

A PUBLISHED CONSTANT THAT IS WRONG, CONTRADICTED BY THE PAGE'S OWN EXAMPLE TABLE. The last Notes bullet reads: "The result is computed by dividing the timestamp (converted to milliseconds) by the number of milliseconds in a day and adding 25,568." For timestamp 0 that recipe yields serial 25,568. But the same page's example table prints timestamp 0 -> 1/1/1970 0:00:00, and in the 1899-12-30-origin serial system Google Sheets uses, 1970-01-01 is serial 25569, not 25568: (1970-01-01) - (1899-12-30) = 25569 days, verified independently. The constant in the Notes is one day short. This corpus asserts 25569 -- the value the page's own worked example requires -- and records the Notes bullet as the error. The bullet was re-read on a second, separate fetch on 2026-08-31 to rule out a transcription slip; it says 25,568 both times. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED ROW, ASSERTED BELOW THE PRECISION IT DISPLAYS. The table prints timestamp 1655906568893 with =EPOCHTODATE(A2,2) -> 6/22/2022 14:02:49, but 1655906568.893 s after the epoch is 14:02:48.893 UTC, not 14:02:49 -- the published cell is the DISPLAY of a value whose seconds field has been rounded by the cell's number format, not a different value. This case asserts the underlying quantity as seconds past midnight, 14*3600 + 2*60 + 48.893 = 50568.893, which is consistent with the published display and with the Note "Fractional amounts of milliseconds are shortened". Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1656356678000410 with =EPOCHTODATE(A6,3) -> 6/27/2022 19:04:38. Independently recomputed as 2022-06-27T19:04:38.000410Z, i.e. 19*3600 + 4*60 + 38 = 68678 seconds past midnight. Asserted at three decimals, ONE THOUSAND TIMES COARSER than the input's resolution, deliberately: 410 microseconds is far below what a day-based serial number can carry, so asserting it would test the float, not the function. What this case does establish is that unit 3 divides by a million -- any other unit puts the result in a different year. "Negative timestamps aren't accepted" is the page's only other constraint and it names no error value, so nothing is asserted about negative input. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1655906710 with =EPOCHTODATE(A3,1) -> 6/22/2022 14:05:10. Independently recomputed as 1970-01-01T00:00:00Z + 1655906710 s = 2022-06-22T14:05:10Z. Asserted through TEXT with an explicit unambiguous pattern rather than against the page's US-format display string, so that a cell's number format cannot decide the case. The Note that makes UTC the right frame reads: "The result will be in UTC, not the local time zone of your spreadsheet." EPOCHTODATE's page carries a real Timestamp/Result/Formula table in the article body, so the five rows below are Google's own published outputs rather than derivations. Each was independently recomputed here from the Unix epoch in UTC before being written down, and all five reproduce. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1584033897 with =EPOCHTODATE(A5) -> 3/12/2020 17:24:57. Independently recomputed as 2020-03-12T17:24:57Z. This is the row that pins the default, and the Note agrees: "Seconds is the default unit of time." Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 0 with =EPOCHTODATE(A4,2) -> 1/1/1970 0:00:00. Asserted as a difference against DATE(1970,1,1) so that no date format enters the comparison. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

A PUBLISHED CONSTANT THAT IS WRONG, CONTRADICTED BY THE PAGE'S OWN EXAMPLE TABLE. The last Notes bullet reads: "The result is computed by dividing the timestamp (converted to milliseconds) by the number of milliseconds in a day and adding 25,568." For timestamp 0 that recipe yields serial 25,568. But the same page's example table prints timestamp 0 -> 1/1/1970 0:00:00, and in the 1899-12-30-origin serial system Google Sheets uses, 1970-01-01 is serial 25569, not 25568: (1970-01-01) - (1899-12-30) = 25569 days, verified independently. The constant in the Notes is one day short. This corpus asserts 25569 -- the value the page's own worked example requires -- and records the Notes bullet as the error. The bullet was re-read on a second, separate fetch on 2026-08-31 to rule out a transcription slip; it says 25,568 both times. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED ROW, ASSERTED BELOW THE PRECISION IT DISPLAYS. The table prints timestamp 1655906568893 with =EPOCHTODATE(A2,2) -> 6/22/2022 14:02:49, but 1655906568.893 s after the epoch is 14:02:48.893 UTC, not 14:02:49 -- the published cell is the DISPLAY of a value whose seconds field has been rounded by the cell's number format, not a different value. This case asserts the underlying quantity as seconds past midnight, 14*3600 + 2*60 + 48.893 = 50568.893, which is consistent with the published display and with the Note "Fractional amounts of milliseconds are shortened". Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1656356678000410 with =EPOCHTODATE(A6,3) -> 6/27/2022 19:04:38. Independently recomputed as 2022-06-27T19:04:38.000410Z, i.e. 19*3600 + 4*60 + 38 = 68678 seconds past midnight. Asserted at three decimals, ONE THOUSAND TIMES COARSER than the input's resolution, deliberately: 410 microseconds is far below what a day-based serial number can carry, so asserting it would test the float, not the function. What this case does establish is that unit 3 divides by a million -- any other unit puts the result in a different year. "Negative timestamps aren't accepted" is the page's only other constraint and it names no error value, so nothing is asserted about negative input. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1655906710 with =EPOCHTODATE(A3,1) -> 6/22/2022 14:05:10. Independently recomputed as 1970-01-01T00:00:00Z + 1655906710 s = 2022-06-22T14:05:10Z. Asserted through TEXT with an explicit unambiguous pattern rather than against the page's US-format display string, so that a cell's number format cannot decide the case. The Note that makes UTC the right frame reads: "The result will be in UTC, not the local time zone of your spreadsheet." EPOCHTODATE's page carries a real Timestamp/Result/Formula table in the article body, so the five rows below are Google's own published outputs rather than derivations. Each was independently recomputed here from the Unix epoch in UTC before being written down, and all five reproduce. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1584033897 with =EPOCHTODATE(A5) -> 3/12/2020 17:24:57. Independently recomputed as 2020-03-12T17:24:57Z. This is the row that pins the default, and the Note agrees: "Seconds is the default unit of time." Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 0 with =EPOCHTODATE(A4,2) -> 1/1/1970 0:00:00. Asserted as a difference against DATE(1970,1,1) so that no date format enters the comparison. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

A PUBLISHED CONSTANT THAT IS WRONG, CONTRADICTED BY THE PAGE'S OWN EXAMPLE TABLE. The last Notes bullet reads: "The result is computed by dividing the timestamp (converted to milliseconds) by the number of milliseconds in a day and adding 25,568." For timestamp 0 that recipe yields serial 25,568. But the same page's example table prints timestamp 0 -> 1/1/1970 0:00:00, and in the 1899-12-30-origin serial system Google Sheets uses, 1970-01-01 is serial 25569, not 25568: (1970-01-01) - (1899-12-30) = 25569 days, verified independently. The constant in the Notes is one day short. This corpus asserts 25569 -- the value the page's own worked example requires -- and records the Notes bullet as the error. The bullet was re-read on a second, separate fetch on 2026-08-31 to rule out a transcription slip; it says 25,568 both times. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED ROW, ASSERTED BELOW THE PRECISION IT DISPLAYS. The table prints timestamp 1655906568893 with =EPOCHTODATE(A2,2) -> 6/22/2022 14:02:49, but 1655906568.893 s after the epoch is 14:02:48.893 UTC, not 14:02:49 -- the published cell is the DISPLAY of a value whose seconds field has been rounded by the cell's number format, not a different value. This case asserts the underlying quantity as seconds past midnight, 14*3600 + 2*60 + 48.893 = 50568.893, which is consistent with the published display and with the Note "Fractional amounts of milliseconds are shortened". Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1656356678000410 with =EPOCHTODATE(A6,3) -> 6/27/2022 19:04:38. Independently recomputed as 2022-06-27T19:04:38.000410Z, i.e. 19*3600 + 4*60 + 38 = 68678 seconds past midnight. Asserted at three decimals, ONE THOUSAND TIMES COARSER than the input's resolution, deliberately: 410 microseconds is far below what a day-based serial number can carry, so asserting it would test the float, not the function. What this case does establish is that unit 3 divides by a million -- any other unit puts the result in a different year. "Negative timestamps aren't accepted" is the page's only other constraint and it names no error value, so nothing is asserted about negative input. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.