max
max
PostsComments
PPrisma
Created by max on 4/15/2025 in #help-and-questions
Handling @db.Date fields client side from different Timezones (Postgres)
@Nurul I think I discovered a bug in prisma/adapter-pg: If before instanciating the Prisma Client i add my own parser like so: 
import { types as pgTypes } from 'pg';

pgTypes.setTypeParser(1082, (val) => {
  console.log("my parser used");
  return `${val}`;
});
import { types as pgTypes } from 'pg';

pgTypes.setTypeParser(1082, (val) => {
  console.log("my parser used");
  return `${val}`;
});
This should make prisma convert Dates using this mapping function. However, the following code from prisma/adapter-pg/index.js line 107 makes it so that if there is a custom-parser (internally from prisma) that one is used instad of my overwrite. Is this the desired behavior? 
 getTypeParser: (oid: number, format?) => {
      if (format === 'text' && customParsers[oid]) {
        return customParsers[oid]; //<----- here the prisma internal Date mapper is used instead of my global override
      }

      return types.getTypeParser(oid, format)
 },
 getTypeParser: (oid: number, format?) => {
      if (format === 'text' && customParsers[oid]) {
        return customParsers[oid]; //<----- here the prisma internal Date mapper is used instead of my global override
      }

      return types.getTypeParser(oid, format)
 },
7 replies
PPrisma
Created by max on 4/15/2025 in #help-and-questions
Handling @db.Date fields client side from different Timezones (Postgres)
@Nurul (Prisma) Yes thats exactly the desired behavior. How can I implement a general solution that doesn't require hand picking the date only fields and mapping them? Is that where @prisma/adapter-pg comes into play? to parse db.Date differently when reading from postgres?
7 replies
PPrisma
Created by max on 4/17/2025 in #help-and-questions
Is there a way to differently parse DateTime and db.Date when reading from Postgres
This allows me when reviving the JSOn client side after it came in from http to be converted correctly by looking for the prefix "DATEONLY-"
7 replies
PPrisma
Created by max on 4/17/2025 in #help-and-questions
Is there a way to differently parse DateTime and db.Date when reading from Postgres
@Nurul (Prisma) this code snipped should technically when reading from postgres convert db.Date differently than DateTime, which doesn't seem to work but it should. Maybe this is possible with @prisma/adapter-pg?
7 replies
PPrisma
Created by max on 4/17/2025 in #help-and-questions
Is there a way to differently parse DateTime and db.Date when reading from Postgres
somewhat similar but i was more looking for something like this which doesn't work for some reason: 
import pg from 'pg';

pg.types.setTypeParser(1082, (val) => {
  return `DATEONLY-${val}`;
});
import pg from 'pg';

pg.types.setTypeParser(1082, (val) => {
  return `DATEONLY-${val}`;
});
7 replies
PPrisma
Created by max on 4/15/2025 in #help-and-questions
Handling @db.Date fields client side from different Timezones (Postgres)
The pitfall for this is that basically whichever date and time is saved in the db will be shown locally as the same date and time verywhere in the world. no matter if it was Daylight saving time or not or if youre in New York or in Zürich. This may not be what you desire as this effectively removes timezones alltogether and it could give the false sense of what times mean. If I'm in Switzerland and wanna see what time an employee started working in new York I will see that he started at 7:00 wherever they are located at and it doesn't mean that they started working what for me is 7:00. In our case thats fine but I still wanna ask you guys what the perfect solution to this problem would be. I don't see a generic way to handle this (differentiate between DateTime and db.Date) client side
7 replies
PPrisma
Created by max on 4/15/2025 in #help-and-questions
Handling @db.Date fields client side from different Timezones (Postgres)
Or is the solution simply to adjust ALL dates when reading and writing by their current timezone? Any date that the client sends will add/subtract its timezone offset when writing to the DB. There is a gotcha for this solution that I'll mention after but is it still applicable or am I overlooking something Example for db.Date fields 1. Client picks date( date only) from date picker (this will likely be a date with hours,minutes at 0, so "2025-04-20T00.00.000Z-4" 2. We send this date by adding the timezone offset so it becomes "2025-04-20T00.00.000Z" ( basically same date and time with timezone cutt off) 3, Postgres saves this as a date only a db.Date "2025-04-20" 4. Client receives this date originally as "2025-04-20T00.00.000Z" which translates locally to "2025-04-19T20.00.000Z-4" but we now adjust for that offset again and convert it to "2025-04-20T00.00.000Z-4" to get the beginning of that date for the local timezone to make it compatible again with client code Example for regular DateTime fields 1. Client picks a date & time for something like an Event: "2025-04-20T07.00.000Z-4", so 7:00 at local timezone in New York 2. again this gets send and stored with the local offset adjusted for and results db side in "2025-04-20T07.00.000Z", so simply the same time but the offset removed (without the adjustment in the DB would be 11:00) 3. Client reads the DateTime from the server which as "2025-04-20T07.00.000Z" and converts it to "2025-04-20T07.00.000Z-4"
7 replies
PPrisma
Created by max on 2/20/2025 in #help-and-questions
Parameterized Views for postgres 🦄
@Nurul (Prisma) I forgot to mention you, so you probably didn't receive a notification. Any input would be greatly appreciated
7 replies
PPrisma
Created by max on 2/20/2025 in #help-and-questions
Parameterized Views for postgres 🦄
If I simply extend the view in the schema by some made up property holder to make it appear in the type like to : 
view PersonTime {
    view_param_date_start DateTime?
    // All regular colums that actually exist on the view
}
view PersonTime {
    view_param_date_start DateTime?
    // All regular colums that actually exist on the view
}
then of course we have type support for: include: {workingTime: {where: {view_param_date_start: "2025-01-01"}}} This actually works if I write an extension for $allOperations that - looks through the args, extracts all parameters that it finds that start with (defined by convention) "viewp_param_xyz", - deletes them from the args and and sets them as omit: {view_param_xyz}. - set the extracted params like in the Original pst via transaction. It has to be omitted or else prisma tries to find it in the View where it actually doesn't exist since we just faked it for type support. But its by all means not a clean solution.
7 replies
PPrisma
Created by max on 2/20/2025 in #help-and-questions
Parameterized Views for postgres 🦄
Thanks for the response. Do you have any input on how I could make the passing of the viewParams better? Currently we do 
prisma.$extends(withParams({dateRangeStart})).person.findMany({include: {workingTime: true}).
prisma.$extends(withParams({dateRangeStart})).person.findMany({include: {workingTime: true}).
What would be the dream: 
prisma.person.findMany(
  {include: {workingTime: {viewParams: {dateRangeStart}}}
)
prisma.person.findMany(
  {include: {workingTime: {viewParams: {dateRangeStart}}}
)
To make such an extension for one model would probably be somehow (if even at all?) possible to extend the type and react on its existence to set session variables like before, but as soon as we include from another path like account.person.workingTime, this wouldn't work anymore Is it somehow possible to extend a specific type like WorkingTimeWhereArgs? Cause if so then it would probably be possible generically and we'd just have to add another extension that looks through the entire args and if it finds a viewParams section it writes them to the session variables
7 replies