Comments (9)
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:
- The value in database is correct, as shown in the pic. In fact, the data type is DateTime.
- For the same object type, if I return it directly from query, it is returning the date time in 2024-05-26T00:00:00.
- 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.
- 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.
Related Issues (20)
- Altair schema doesn't support for generic type HOT 5
- [Bug] Failed to register with generic class HOT 2
- Mutation return void HOT 2
- Question about mapping HOT 4
- Enum return capital case HOT 6
- Error format in NGraphQL HOT 3
- Version 1.2 published
- Subscription HOT 2
- Should the model mapping based on GraphQLName? HOT 5
- Version 1.3.0 published - Map Scalar type (Dict<string, object>)
- GraphQL and strongly-typed languages like c#, continued from other thread HOT 1
- Version 1.4 is published - compliance with Official Spec 2021 version
- Empty json input causing error HOT 3
- An article on medium
- Query type field HOT 2
- Object type as Input type HOT 2
- DateTime is not returned in UTC HOT 7
- No longer run after upgraded to ver 1.7 HOT 2
- Subscription example HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ngraphql.