jakubfijalkowski
commented
2 years ago it should cover most of the usecases
I disagree. This covers only the case where use needs to pass the date, which is only one case. When you need to display the date, you don't know what to display because the offset is lost. We need to handle that.
Is that what you meant @jakubfijalkowski ?
Unfortunately, no. We can't use DateTime in place of DateTimeOffset - this will never work. The simplest solution is the one TS generator took - do not try to use stdlib Date object in place of DateTime and DateTimeOffset but use string there. Here, Dart's DateTime covers the DateTime type in contracts (although I fear it might convert to "local" timezone where they should not - DateTime in contracts is strictly UTC), so the only problem is DateTimeOffset.
The best solution would be to introduce custom DateTimeOffset type*, just like DateOnly, but that is a lot of work to do correctly. The other solution is to depend on some library that provides this type, but I really don't want to do so (too opinionated). Another one is to make this pluggable, i.e. allow configuring the type. The worst, but still sensible, solution, is to translate DateTimeOffset to string and leave the decision on what to use to the client app.
* - it can even be a simple wrapper for DateTime (UTC) + int offsetInMinutes, then the app will be able to convert it to their desired type using app-local extensions.
This is not a complete solution to #56, but it should cover most of the usecases. Is that what you meant @jakubfijalkowski ? I'll add some tests if so