Giters

danieleteti / delphimvcframework

DMVCFramework (for short) is a popular and powerful framework for WEB API in Delphi. Supports RESTful and JSON-RPC WEB APIs development.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bug: Render Dataset datetime field adds incorrect timezone

fastbike opened this issue · comments

commented

I have a dataset with a DateTime field, which contains local server times. When this is rendered it has the "Z" (Zulu) timezone added to the json data.
So a value that is 2020/07/31@14:30:12.250 is rendered as 2020-07-31T14:30:12.250Z rather than the 2020-07-31T14:30:12.250+12:00 we would expect to see from the server time zone.
This means the time as rendered is actually incorrect by 12 hours !

The code that does the rendering is in the TMVCJsonDataObjectsSerializer.DataSetToJsonObject method. For DateTime fields it calls DateTimeToISOTimeStamp (in the MVCFramework.Serializer.Commons.pas unit) which calls DateToISO8601 passing through a hardcoded value of True for the second param of "InputIsUTC"
Because of this hard coded param all dates are assumed to be encoded to UTC with zero offset, so local dates are not handled correctly.

I can see a couple of ways to fix this:

  • change the storage of the dates in the database from local to UTC. Unfortunately we do not control the database.
  • change the call to DateToISO8601 to pass through False as the second param. This may break existing applications.
  • add an additional param to DateTimeToISOTimeStamp to allow InputIsUTC to be specified, with a default value of True.
    This could be specified with a set of options that can be passed through to the Serialiser call (I can see other options that could be added over time for formatting).

Let me know what you think and I can mock up some potential changes with test cases.

commented

I think that the 2nd option is the more correct one. Application which don't use timezone, will not break. Those who use timezoe will be "more" correct. I think that we should test for this solution. Can you do some checks on your side?

commented

I'd like to fix this bug before the 3.2.1-carbon release.

commented

OK, I will make the fix in my app and test (this week)

commented

News?

commented

Please, check the proposed solution in the repo. Is works for all unit tests considering all the internal date representation as local but serialization and deserialization accept a valid UTC format. Following the specs a datetime string without UTC specification is considered as "local to the server".

commented
commented

It should be solved in the repo. Thank you for your support.