Fix date type update #9700

lucasbordeau · 2025-01-16T17:37:43Z

This PR fixes a problem with how TypeORM handles date without time.

A date without time that is stored in PostgreSQL database as date type gets returned as an ISO string date with a timezone that can shift its date part in an unwanted way.

In short DB stores 2025-01-01, TypeORM query builder returns 2024-12-31T23:00:00Z which gets parsed as 2024-12-31 on the front end field.

We don't want to handle timezone here because we are manipulating a date without its time part, so this PR adds a step that counteracts what TypeORM does and returns 2025-01-01T00:00:00.000Z so that the front can parse it correctly.

@Weiko We might want to check other places of the backend where date types are returned by TypeORM, we might have the same problem, this PR only fixes it for updateOne resolver return.

Fixed date persist on frontend which was shifting the date to a different day due to timezone issue
Fixed date returned by the backend update logic, which was shifting the date by the timezone offset (so this PR adds back the offset so that it stays at 00:00:00Z time)

greptile-apps

PR Summary

This PR addresses timezone-related issues in date handling across the frontend and backend, ensuring consistent date persistence at 00:00:00Z time.

Modified DateFieldInput to manually construct YYYY-MM-DD strings instead of using toISOString() to prevent timezone shifts
Added timezone offset compensation in format-result.util.ts to maintain dates at 00:00:00Z time
Renamed InternalDatePicker to DateTimePicker and improved timezone handling using Luxon's DateTime
Added proper timezone handling in FormDateTimeFieldInput using user's timezone context
Should remove debug console.log statements before merging to production

_{9 file(s) reviewed, 13 comment(s)}
_{Edit PR Review Bot Settings | Greptile}

greptile-apps · 2025-01-16T17:38:38Z

...-front/src/modules/object-record/record-field/meta-types/input/components/DateFieldInput.tsx

+      const newDateWithoutTime = `${newDate?.getFullYear()}-${(
+        newDate?.getMonth() + 1
+      )
+        .toString()
+        .padStart(2, '0')}-${newDate?.getDate().toString().padStart(2, '0')}`;



style: getMonth() returns 0-11, so adding 1 is correct, but this date construction could be simplified using toISOString().split('T')[0] which would be more reliable

greptile-apps · 2025-01-16T17:38:43Z

packages/twenty-front/src/modules/object-record/record-field/meta-types/hooks/useDateField.ts

+  console.log({
+    fieldValue,
+  });


style: Remove debugging console.log before merging to production

...rc/modules/object-record/object-filter-dropdown/components/ObjectFilterDropdownDateInput.tsx

greptile-apps · 2025-01-16T17:39:37Z

packages/twenty-front/src/modules/ui/field/input/components/DateInput.tsx

@@ -104,16 +122,16 @@ export const DateInput = ({

  return (
    <div ref={wrapperRef}>
-      <InternalDatePicker
+      <DateTimePicker
        date={internalValue ?? new Date()}


logic: Using new Date() as fallback could cause timezone issues. Consider using a timezone-aware default or UTC date.

packages/twenty-front/src/modules/ui/field/input/components/DateInput.tsx

greptile-apps · 2025-01-16T17:39:43Z

.../twenty-front/src/modules/object-record/record-table/hooks/internal/useSetRecordTableData.ts

+        console.log({
+          records,
+        });


style: Debug console.log statement should be removed before merging to production

greptile-apps · 2025-01-16T17:39:48Z

...twenty-front/src/modules/ui/input/components/internal/date/components/InternalDatePicker.tsx

+    console.log('handleClose', {
+      newDate,
+    });
  };


style: Remove console.log statements before merging to production

greptile-apps · 2025-01-16T17:39:49Z

...twenty-front/src/modules/ui/input/components/internal/date/components/InternalDatePicker.tsx

+    console.log('handleDateChange', {
+      dateParsed,
+    });
+


style: Remove console.log statements before merging to production

greptile-apps · 2025-01-16T17:39:50Z

...twenty-front/src/modules/ui/input/components/internal/date/components/InternalDatePicker.tsx

+    console.log('handleDateSelect', {
+      dateParsed,
+    });
+


style: Remove console.log statements before merging to production

packages/twenty-server/src/engine/twenty-orm/utils/format-result.util.ts

prastoin

Hello there ! I'm not 100% sure to understand the initial issue
Left few questions
Please let me know !

packages/twenty-server/src/engine/twenty-orm/utils/format-result.util.ts

prastoin · 2025-01-17T09:43:38Z

packages/twenty-server/src/engine/twenty-orm/utils/format-result.util.ts

+  for (const dateFieldMetadata of dateFieldMetadataCollection) {
+    const currentDate = new Date(newData[dateFieldMetadata.name]);
+
+    const offsetInMilliseconds = -(new Date().getTimezoneOffset() * 60000);


Question: Unless I'm mistaken the API's instance timezone might not be than the same the client that sent or will display the data initially ?

Ok I'll update the naming to reflect the fact that we are countering a problem with TypeORM which automatically converts a date only string '2025-01-01' to a Date ISO string and that it adds the timezone of the server to then convert it back to UTC, thus subtracting the timezone offset of the raw date and ending up with a different day.

In short 2025-01-01 in DB, is returned as 2024-12-31 because of the returning() function of TypeORM, which seems to be an opinionated design decision.

Ok I got it ! Thanks a lot for these explanations makes sense !

TypeORM newbie here, feels bit weird to have to make that mapping manually. I'm wondering if there're no native solution to store date along their timezone ?

Again sorry for nitpicking, but unless I'm mistaken there're might be a world where the API instance that inserted the date is located in a different timezone than the one extracting them ?
As from my understanding, we keep in db dates values that needs to be contextualized each time we wanna retrieve them ?

For reference, here is how PostgreSQL stores a date type (which is PostgreSQL-specific, not TypeORM-specific) :

And here is how PostgreSQL stores a timestamptz type, which corresponds to what you talk about from what I understand :

What is necessary to understand for datetime handling in Twenty is that we decided to store a date+time as a point in time, unique, the same for all timezone, and this is done with timestamptz which stores the timezone, but the important thing to understand is that no matter what timezone get stored, the point in time is the same whether expressed in UTC or CET.

The timestamp type on the contrary doesn't store this timezone information, thus we cannot rely on it to know which precise point in time it is, because the timezone information is lost, and there's no way to reliably know it except by taking assumptions that have to be documented somewhere, plus libraries, client computer / server computer that have different timezone, the native JavaScript Date object being nasty with timezone (you cannot change its timezone) plus difficulty to wrap your head around all of that on a bad day, and this is the beginning of huge problems when working with multiple timezones or daylight save time changes.

https://www.postgresql.org/docs/current/datatype-datetime.html

For our date type, that would be interesting to think about it, for now I think that the consensus is that we only store the date expressed as a simple day in the calendar for someone locally, which is the equivalent of losing the timezone information but here we don't really care because we don't want to know where exactly in time is someone's birthday but rather what day of the year it is.

I think that if someone would want to define a meeting date for people in different timezones, that person would necessary have to use a DateTime type in Twenty, which would display the same point in time for different people in their respective timezone. Because anyway people would ask, ok but when during that day in my timezone ? Because we have 10 hours of difference.

...rc/modules/object-record/object-filter-dropdown/components/ObjectFilterDropdownDateInput.tsx

...ront/src/modules/object-record/record-field/form-types/components/FormDateTimeFieldInput.tsx

...-front/src/modules/object-record/record-field/meta-types/input/components/DateFieldInput.tsx

prastoin · 2025-01-17T11:21:13Z

packages/twenty-server/src/engine/twenty-orm/utils/format-result.util.ts

+      (field) => field.type === FieldMetadataType.DATE,
+    );
+
+  // This is a temporary fix to handle a bug in the frontend where the date gets returned in the wrong timezone,


Praise: 🚀

packages/twenty-server/src/engine/twenty-orm/utils/format-result.util.ts

lucasbordeau added 2 commits January 16, 2025 15:21

WIP

9cce745

Fixed date type update

b04ea49

lucasbordeau requested a review from Weiko January 16, 2025 17:37

Merge branch 'main' into fix/date-input

670a435

greptile-apps bot reviewed Jan 16, 2025

View reviewed changes

lucasbordeau added 2 commits January 17, 2025 10:49

Handled undefined date

81650f7

Merge branch 'main' into fix/date-input

54f4030

prastoin reviewed Jan 17, 2025

View reviewed changes

...-front/src/modules/object-record/record-field/meta-types/input/components/DateFieldInput.tsx Show resolved Hide resolved

lucasbordeau added 2 commits January 17, 2025 11:32

Merge branch 'main' into fix/date-input

9fd7601

Fixed lint and added more self-explanatory naming and comments

c525e00

prastoin reviewed Jan 17, 2025

View reviewed changes

lucasbordeau mentioned this pull request Jan 17, 2025

Updating a date type field makes the date go one day before the selected date. #9698

Closed

Merge branch 'main' into fix/date-input

9bbbc98

Weiko reviewed Jan 17, 2025

View reviewed changes

packages/twenty-server/src/engine/twenty-orm/utils/format-result.util.ts Outdated Show resolved Hide resolved

Fixed comment

636b947

Weiko approved these changes Jan 17, 2025

View reviewed changes

lucasbordeau merged commit 6bd0244 into main Jan 17, 2025
47 checks passed

lucasbordeau deleted the fix/date-input branch January 17, 2025 15:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix date type update #9700

Fix date type update #9700

lucasbordeau commented Jan 16, 2025 •

edited

Loading

greptile-apps bot left a comment

greptile-apps bot Jan 16, 2025

greptile-apps bot Jan 16, 2025

greptile-apps bot Jan 16, 2025

greptile-apps bot Jan 16, 2025

greptile-apps bot Jan 16, 2025

greptile-apps bot Jan 16, 2025

greptile-apps bot Jan 16, 2025

prastoin left a comment •

edited

Loading

prastoin Jan 17, 2025 •

edited

Loading

lucasbordeau Jan 17, 2025 •

edited

Loading

prastoin Jan 17, 2025 •

edited

Loading

lucasbordeau Jan 17, 2025 •

edited

Loading

lucasbordeau Jan 17, 2025

lucasbordeau Jan 17, 2025 •

edited

Loading

prastoin Jan 17, 2025

Fix date type update #9700

Fix date type update #9700

Conversation

lucasbordeau commented Jan 16, 2025 • edited Loading

greptile-apps bot left a comment

Choose a reason for hiding this comment

PR Summary

greptile-apps bot Jan 16, 2025

Choose a reason for hiding this comment

greptile-apps bot Jan 16, 2025

Choose a reason for hiding this comment

greptile-apps bot Jan 16, 2025

Choose a reason for hiding this comment

greptile-apps bot Jan 16, 2025

Choose a reason for hiding this comment

greptile-apps bot Jan 16, 2025

Choose a reason for hiding this comment

greptile-apps bot Jan 16, 2025

Choose a reason for hiding this comment

greptile-apps bot Jan 16, 2025

Choose a reason for hiding this comment

prastoin left a comment • edited Loading

Choose a reason for hiding this comment

prastoin Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

lucasbordeau Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

prastoin Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

lucasbordeau Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

lucasbordeau Jan 17, 2025

Choose a reason for hiding this comment

lucasbordeau Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

prastoin Jan 17, 2025

Choose a reason for hiding this comment

lucasbordeau commented Jan 16, 2025 •

edited

Loading

prastoin left a comment •

edited

Loading

prastoin Jan 17, 2025 •

edited

Loading

lucasbordeau Jan 17, 2025 •

edited

Loading

prastoin Jan 17, 2025 •

edited

Loading

lucasbordeau Jan 17, 2025 •

edited

Loading

lucasbordeau Jan 17, 2025 •

edited

Loading