DateTime with Timezone, inconsistent between Query and Mutation about ngraphql HOT 9 CLOSED

https://medium.com/@rivantsov/making-time-dependent-features-testable-c-d5feff606ece

from ngraphql.

Not a bug maybe but likely inconsistency, in formatting
Try adding [Utc] to field in Entity. It actually should be there, anyway, if you store all in UTC, as you should I think

from ngraphql.

The thing is, if adding the utc tag, the front end will need to do the conversion to local time, otherwise it may lose one day due to time zone, as the expiry date is for date only. The front end expect what they store is what they see without any conversion required. That's why we don't add the utc tag.

Anyway, i guess this issue may only happen in our local development. The live environment server is always in utc time zone. It is just quite annoying for front end when testing locally.

Would appreciate to have this fix if it is not a major changes.

Thanks!

from ngraphql.

Found a workaround solution, closing now.

from ngraphql.

Hi again,
sorry for being late, good you found workaround, but I want to ask a few more question to make it clear for me.
So, the problem is in NGraphQL (deserialization or serialization?), or it is Vita and MySQL?
After the mutation call, is the value in the database correct, what you want it to be? - note that the pic you show, I guess it is SQL browser, it is a string representation (!) of the value in SQL browser (!). But the real value in Db - are you happy with it? and problem is then with NGraphQL query, how the date is formatted by deserializer?
So if there is a problem, where is it - NGraphQL or VITA, and what it is?

General note/advice. I follow the rule to NEVER use DateTime.Now in the code, always DateTime.UtcNow (or better AppTime.UtcNow), for reason you mentioned - in cloud all servers run on UTC, so with UtcNow the code runs the same, on local machine on in the cloud. Recommend to follow the same rule - all datetime values in the app and in database is UTC.
. If you have need for user's local time, you know user's timezone, and convert on the fly, on server (so Graphql json response contains converted dates), or on the client. For example, if you have online meeting with participants in multiple time zones, this method works for all of them, when you send reminders or show time in their local time.

from ngraphql.

Hi @rivantsov ,

Thanks for looking into this again.

I am not sure which part is going wrong:

1. The value in database is correct, as shown in the pic. In fact, the data type is DateTime.
2. For the same object type, if I return it directly from query, it is returning the date time in 2024-05-26T00:00:00.
3. For the same object type, if I return it from mutation, where after the object is created, it is returning the date time in 2024-05-26T00:00:00+08:00.
4. Indeed my workaround is to use DateTime.UtcNow, then somehow it will return me the value 2024-05-26T00:00:00 both in query and mutation.

I believe when the date time is not an UTC kind, the parser will try to convert it into UTC datetime, hence the addon timezone details. Whereas for the query case, the value is retrieved and stored directly in UTC datetime, hence no further conversion has been made.

Btw, for my clarity, may I know is Vita always keep the value retrieve from database as Utc kind or only when the member is annotated with Utc flag?

Once again, thank you for your time in this issue.

from ngraphql.

thanks for the detailed response. I will probably need some time to investigate it deeper, I know I struggled a lot with this datetime mess. I once talked to a guy in Windows Kernel, and his whole career was about this DateTime handling. He admitted that adding this DateTime.Kind flag was the biggest mistake ever in original design, and as a consequence is all this mess we have now; everywhere we have to deal with this (like values coming into and from deserialization). It is quite challenging to take care of all these 'conversion' points, in a consistent way.
I think [Utc] flag causes Vita to automatically convert to Utc any incoming values which are Local time; and to return DateTime column values as Kind=Utc. Then comes conversion inside Json serializer. I think the difference for you comes from the fact that for mutation, you return value copied from input object, not from entity column. I will need to look more into this, as I currently switch serializer to System.Text.Json, as MS pushes for, looks like it is the future. Good that you have workaround for now, and main thing - value is saved in db correctly. We will fine-tune logic later.

from ngraphql.

and using UtcNow - that's the way to go anyway, never DateTime.Now. Better even AppTime.UtcNow

from ngraphql.

Hi @rivantsov ,

I will definitely take a look at AppTime.UtcNow.
Thanks for this great library, it makes the graphql so easy and fun. :)

Thank you!

from ngraphql.