Little John wrote: Mon Dec 25, 2023 2:26 pm
Well, this is also a
bug report, since the above results of FormatDate() and ParseDate() are wrong anyway:
Code: Select all
Define.q date = Date(12345, 1, 2, 3, 4, 5)
Debug FormatDate("%dd.%mm.%yyyy %hh:%ii:%ss", date)
; output : 02.01.1234 03:04:05
; expected by me: 02.01.12345 03:04:05
Debug ParseDate("%dd.%mm.%yyyy %hh:%ii:%ss", "02.01.12345 03:04:05")
; output : -1
; expected by me: 327403479845
You expect
FormatDate() to replace the token
%yyyy with 5 digits, although the documentation says that it replaces with 4 digits.
You expect
ParseDate() to read 5 digits with the token
%yyyy, although the documentation says that it only reads 4 digits.
It is not documented that
%yyyy is the full year, although it was assumed before version 6.10 because the year could not be greater than 4 digits.
Ok, the documentation is a bit imprecise because e.g.
%dd also accepts one digit, not just two digits.
Taking the current documentation into account, I don't see it as a bug, which is why I didn't want to report it as such. But yes, many would probably assume that
%yyyy in version 6.10 now corresponds to 4 up to 5 digits of the year.
In my initial post, I thought it would make sense to keep
%yyyy as is for backwards compatibility reasons, except that it then takes the last 4 digits of the year into account if the year has 5 digits. A new token
%yyyyy (5 times "y" — or 6 times "y" for better visual differentiation) would then correspond to 4 or 5 digits of the year. The reason I thought of, for example, that
%yyyy in ParseDate() should continue to match only 4 digits is, that someone uses ParseDate() for a simple plausibility check of the user input, where the year must have 4 digits and a year with more or less than 4 digits is evaluated as a typing error. Of course, a RegEx check would be better here.
freak wrote: Mon Dec 25, 2023 4:06 pm
juergenkulow wrote: Mon Dec 25, 2023 3:03 pm
Code: Select all
; The last second of the year 1969 does not exist for FormatDate.
That is on purpose. The value -1 has always meant "invalid date" in the PB date library so we have to keep that for backward compatibility. Changing that would break a lot of code so having this one specific second be non-representable is the lesser of two evils here.
It would be good if this were mentioned in the documentation of
FormatDate().
