Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 21:30
    roji commented #2307
  • Jan 31 2019 20:35
    YohDeadfall commented #2307
  • Jan 31 2019 10:20
    capan starred npgsql/npgsql
  • Jan 31 2019 06:10
    SeanFarrow synchronize #2308
  • Jan 30 2019 20:37
    austindrenski commented #2308
  • Jan 30 2019 20:37
    pentagra commented #1445
  • Jan 30 2019 20:33
    SeanFarrow commented #2308
  • Jan 30 2019 20:31
    austindrenski commented #2308
  • Jan 30 2019 20:27
    SeanFarrow commented #2308
  • Jan 30 2019 20:09
    austindrenski labeled #2308
  • Jan 30 2019 20:05
    roji commented #1520
  • Jan 30 2019 19:50
    gyzod commented #1445
  • Jan 30 2019 19:06
    SeanFarrow commented #1520
  • Jan 30 2019 18:54
    roji commented #1520
  • Jan 30 2019 18:53
    roji commented #1520
  • Jan 30 2019 18:52
    roji commented #2050
  • Jan 30 2019 18:45
    Trolldemorted commented #2050
  • Jan 30 2019 18:21
    SeanFarrow commented #1520
  • Jan 30 2019 18:16
    SeanFarrow review_requested #2308
  • Jan 30 2019 18:16
    SeanFarrow review_requested #2308
Shay Rojansky
@roji
Regardless of Npgsql, it's important for the DateTime's Kind to correspond to what's actually being represented
Matthijs ter Woord
@mterwoord:matrix.org
[m]
stuff coming from api's
my api+server side is purely utc
Shay Rojansky
@roji
Like DateTime coming from JSON's being sent by cilents?
Matthijs ter Woord
@mterwoord:matrix.org
[m]
yes
Shay Rojansky
@roji
So if those timestamps really are UTC, I'd look at your JSON deserializer to make it deliver DateTimes with kind UTC
This way in your application you have the right DateTimes
I know it's a pain
Think of DateTimes with different kinds as different .NET types - UTC timestamps and local timestamps really are different things (it's a pity the .NET DateTime type is so badly designed...)
Matthijs ter Woord
@mterwoord:matrix.org
[m]
Sorry for delayed response. Thanks for responding, and suggesting to look at json. I think I fixed (most of) it now. lets see if all tests are green again
Matthijs ter Woord
@mterwoord:matrix.org
[m]
well, the ones caused by this: yes :-)
Thanks!
Matthijs ter Woord
@mterwoord:matrix.org
[m]
Follow-up question: It seems that data retrieved using EFCore doesn't have datetime.kind = utc. Is that something I have to change somewhere as well?
Shay Rojansky
@roji
@mterwoord:matrix.org what is the PostgreSQL column type? For UTC timestamps, it should be timestamp with time zone, and not timestamp without time zone
timestamp with time zone should be the default for DateTime properties in EF Core, so you should get timestamp without time zone only if you're explicitly specifying it
DateTime retrieved from timestamp with time zone should always have Kind=UTC
Matthijs ter Woord
@mterwoord:matrix.org
[m]
hmm, it seems "timestamp" but its all generated by EFC
Shay Rojansky
@roji
With EF Core 6.0?
Are you sure?
Matthijs ter Woord
@mterwoord:matrix.org
[m]
with 3.1 i think
Shay Rojansky
@roji
Ah that's very different indeed
Matthijs ter Woord
@mterwoord:matrix.org
[m]
i made a pgdump yesterday. lets see
Shay Rojansky
@roji
What I wrote above was for 6.0 - there have been significant changes around timestamp handling in that version
Above you said EF Core 6.0 no?
Matthijs ter Woord
@mterwoord:matrix.org
[m]
it seems its all defined with 'without timezone'
i upgraded this project
Matthijs ter Woord
@mterwoord:matrix.org
[m]
i guess i have to upgrade my database schema? (which is definitely an option, if doable via ef migrations)
Shay Rojansky
@roji
Yep
There's instructions for migrating the column types - it's really easy
But read that link carefully
Matthijs ter Woord
@mterwoord:matrix.org
[m]
will re-read
will do reading, but making a migration will automagically upgrade the columns for me?
Shay Rojansky
@roji
It will - but there's something you need to add to that migration after adding it, to make sure there's no bad timezone conversion
Matthijs ter Woord
@mterwoord:matrix.org
[m]
ah
Shay Rojansky
@roji
This all assumes that what you currently have in your database (in your timestamp without time zone columns) is already UTC timestamps
Matthijs ter Woord
@mterwoord:matrix.org
[m]
the set statemnet, i see
Shay Rojansky
@roji
Yep
Matthijs ter Woord
@mterwoord:matrix.org
[m]
yes
and having times/dates switch 1-2 hours wouldn't be a problem, to be honest with you
this is an iot platform. the measurements are in elasticsearch anyway..
:)
Shay Rojansky
@roji
OK :)
Better to preserve the data in any case ;)
Matthijs ter Woord
@mterwoord:matrix.org
[m]
yeah, but what i'm saying, is that if there 08:00 in the morning in teh db now, having that shift to 0600 due utc adjustment, that wouldn't be a big deal
Shay Rojansky
@roji
ok
Matthijs ter Woord
@mterwoord:matrix.org
[m]
thanks for explaining though!
Shay Rojansky
@roji
:+1:
Matthijs ter Woord
@mterwoord:matrix.org
[m]
Also, I hop i wasn't too negative: I think the changes are good, just frustrating due to complexity :)
Shay Rojansky
@roji
Not at all - I really understand the frustration... We did this change after lots of thought and were afraid it's too big a change for all the users. But in the end we did decide to do the right thing even if the transition is hard.