ISO-8601 timezone

EMartin · 2014-09-25 21:03:56

Hi, I work with datetime with the following format: YYYY-MM-DDTHH:NN:SS.zzzZ, being zzz=millisenconds and Z=timezone. When I use ISO8601ToDateTime function the last Z is ignored and the datetime is converted regardless the timezone. Then I wrote the following code wrapping the ISO8601ToDateTime function:

class function IMRUtils.ISO8601ToDateTime(const aValue: String): TDateTime;
var
  lTimeZone: TTimeZoneInformation;
begin
  Result := SynCommons.Iso8601ToDateTime(aValue);
  if (aValue <> '') and (aValue[Length(aValue)] in ['Z', 'z']) then
  begin
    GetTimeZoneInformation(lTimeZone);
    Result := IncHour(Result, (lTimeZone.Bias div -60));
  end;
end;

This works fine, but I want to know if the framework support timezone. if so, I could not find.

TIA.

Esteban.

ab · 2014-09-25 23:06:34

The framework uses UTC time by default.

It is to the ui layer to convert to/from local time.

mpv · 2014-09-26 08:23:56

@EMartin code work correctly only for Today() - it not analyze DaylightBias. And DaylightBias is depend not only from winter/summer, but from country lows (before 1970 we do not have Daylight, after have and so on)
So AB right - the easiest way is to convert DateTime to/from UTC in client - client know his Timezone historic table (there is bugs in Windows XP <= SP2 for some timezones).

But there is another problem - in case client convert DateTime to UTC server also must obviously sad to client dates is in UTC format. As I point in this topic current implementation do not do this.
So in my fork of mORMot I made several modification to add 'Z' (and 'T00:00Z' in case of Date w/o time) to the end of time string ( TSQLTableJSON serialization, TJSONSerializer.WriteObject ) during serialization result to client.

ab · 2014-09-26 10:36:15

You can indeed add 'Z' to every date/time.

Or use it as UTC value by convention on the client side.

EMartin · 2014-09-26 18:36:33

@ab, @mpv thanks for reply.

I'll investigate how use mORMot UTC with string datetime received from external gateway in the format aforementioned.

Thanks again.

Esteban

mpv · 2021-04-16 19:34:42

I am facing a new unexpected DateTime serialization problem (problem described in topic above is fixed in mORMot by woDateTimeWithZSuffix serializer option).
My current problem is what even with woDateTimeWithZSuffix is ON we serialize a Date (without time) into 'T00:00Z' (without seconds) and Date with time into 'Txx:yy:zzZ' (with seconds).

My API is used by different clients written using different programming languages, and in some languages de-serialization of the ISO date is "pattern based", for example in Oracle such terrible construction is used:

to_timestamp_tz ('2014-09-12T11:53:06Z', 'YYYY-MM-DD"T"HH24:MI:SSTZH:TZM')

and it fails if ISO string is come without seconds in form '2014-09-12T00:00Z'

Something similar is in the Objective-C.

So, my proposal is to add a seconds for dates (change 'T00:00Z' -> 'T00:00:00Z' into mORMot.pas), in this case the same pattern can be used to decode time with and without seconds. I think it should not broke an existed code.

Last edited by mpv (2021-04-16 19:35:46)

ab · 2021-04-16 22:20:22

I guess this is a fair fix.

Could you send some pull requests?
Thanks!

mpv · 2021-04-17 06:12:58

Created PR for mORMot1 https://github.com/synopse/mORMot/pull/391 and mORMot2 https://github.com/synopse/mORMot2/pull/25

ab · 2021-04-17 08:16:03

Merged.

Thanks!

mORMot Open Source

#1 2014-09-25 21:03:56

ISO-8601 timezone

#2 2014-09-25 23:06:34

Re: ISO-8601 timezone

#3 2014-09-26 08:23:56

Re: ISO-8601 timezone

#4 2014-09-26 10:36:15

Re: ISO-8601 timezone

#5 2014-09-26 18:36:33

Re: ISO-8601 timezone

#6 2021-04-16 19:34:42

Re: ISO-8601 timezone

#7 2021-04-16 22:20:22

Re: ISO-8601 timezone

#8 2021-04-17 06:12:58

Re: ISO-8601 timezone

#9 2021-04-17 08:16:03

Re: ISO-8601 timezone

Board footer