String Long time format to DateTime

[dbannon]

WP, I note you are only testing using the *Z format, the so called Zulu time. 

The plus or minus formats are also defined in ISO8601, eg 2020-08-08T19:21:07.8452100+10:00  believe it or not, time zones of 15 minutes increment exist. https://www.worldtimeserver.com/time-zones/acwst/ indicates 2020-08-08T19:21:07.8452100+08:45 is legal (mind you, about six people live in this time zone).

I don't have a trunk FPC install but maybe I can copy the relevant method into my test code ?  Guessing that  its not dependent on other FPC 4.0 things ?

Given FPC release cycle, its worth being just a bit obsessive about.   

Davo

[winni]

Hi!

There are funny things in the time zones.

Nepal likes to have some distance to India:

India: UTC+05:30

Nepal:UTC+05:45


Winni

[dsiders]

I have not because I am hesitant to start fiddling with RTL on my dev machine.

I am attaching a simple demo for a variety of test cases. It prints out the ISO-formatted input string and the decoded date/time, or "Error" if the conversion was not successful. There are still some "Error"s indicating that there is still work to be done. Especially for me because my patch obviously broke the non-separator dates with fractional seconds which works in FPC 3.2 but fails in current trunk (after the patch)...

The accompanying text spells out the precision and decimal point changes. I had to put some number of decimals in the examples. I suppose I could vary the number of digits to make the point.

I see it now. I think it's ok.

@wp:

Just a comment.

ISO 8601 does not allow "/" as separator between elements in a date value. The fact that it works in RTL is an implementation anomaly. It is never validated, and the length is used instead.

ISO 8601 does not allow using a space as the separator between date and time values. to quote: "Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.[34]".

I think the RTL implementation still needs a little more work.

"Standards are a wonderful thing... that's why there are so many of them."

[dbannon]

No, I don't seem to be able to graft the new code into a current env.  The code in FP trunk calls

Code: [Select]

dateutil.inc#2971 GetLocalTimeOffset(TDateTime; Boolean) : integer
  but all I can find in rtl/unix/sysutils.pp is

Code: [Select]

#1807 GetLocalTimeOffset(integer) : integer;
#1813 GetLocalTimeOffset(TDateTime; Boolean; Integer): Boolean;
Can anyone point to where GetLocalTimeOffset(TDateTime; Boolean) : integer lives please.

"Standards are a wonderful thing... that's why there are so many of them."

https://xkcd.com/927/

Davo

[bytebites]

https://github.com/graemeg/freepascal/blob/master/rtl/objpas/sysutils/dati.inc in the end.

[wp]

Just a comment.

ISO 8601 does not allow "/" as separator between elements in a date value. The fact that it works in RTL is an implementation anomaly. It is never validated, and the length is used instead.

ISO 8601 does not allow using a space as the separator between date and time values. to quote: "Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.[34]".

This is not about *creating* an ISO8601-conformal date/time string, but about decoding it. I see no problem when the FPC implementation allows for some extra freedom beyond what defined by the standard because it extends the usability of a function to similar cases. What i do care is that crashes in case of correct date/time strings absolutely must be avoided. And that the result must be correct, of course.

[dbannon]

https://github.com/graemeg/freepascal/blob/master/rtl/objpas/sysutils/dati.inc in the end.

Thanks bytebites, found it. But I was wrong about the rest of the associated code not being that different from 3.2, in fact, there are huge changes. So, after a lot of cut and past, I have decided to get a trunk compiler installed and do my tests on that.

... What i do care is that crashes in case of correct date/time strings absolutely must be avoided. And that the result must be correct, of course.

yep, well said !

Davo

[dbannon]

Yep, that code now in trunk handles my particular corner case beautifully !

Code: [Select]

2020-08-08T19:21:07.7654321+10:00 ---> 2020-08-08T19:21:07.7654320+10:00
(the 0 after the microseconds is because I deliberately round that off in my own formatter)

Thanks WP, if I could use that for production now, would save quite a few lines of code out of my project !

Davo

[dsiders]

Just a comment.

ISO 8601 does not allow "/" as separator between elements in a date value. The fact that it works in RTL is an implementation anomaly. It is never validated, and the length is used instead.

ISO 8601 does not allow using a space as the separator between date and time values. to quote: "Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.[34]".

This is not about *creating* an ISO8601-conformal date/time string, but about decoding it. I see no problem when the FPC implementation allows for some extra freedom beyond what defined by the standard because it extends the usability of a function to similar cases. What i do care is that crashes in case of correct date/time strings absolutely must be avoided. And that the result must be correct, of course.

I would have expected the routine to be called RFC3339ToDateTime in that case... cause that's what is being accepted. Like I said, just a comment.

But, I agree about crashes on valid inputs. Gotta fix it.