#761 Allow 4 digit years for European, Ordered and USA date formats

[Jon Wolfers]

Since the turn of the Century, real life usage of the european date format has always featured 4 digits for the year. I assume the same is true of the Ordered and USA date formats.
To cope with this in my own work I have constructed subclass of the datetime object that accept and produces four digit european dates with these added methods

 ::method fromEuropean4Date class
-- european4Dates are like dd/mm/yyyy
use arg date, separator = '/'
return self~fromStandardDate('7890645312'~translate(date,'1234567890'),separator)

and

 ::method european4Date
-- european4Date dates are like dd/mm/yyyy
use arg separator = '/'
return '9086751234'~translate(self~standardDate(separator),'1234567890')

and also for my convenience to convert a standard datetime to my subclass

 ::method fromDateTime class
use arg datetime
return self~fromIsoDate(dateTime~isoDate)

We are now 20 years after the millenium change. It would be nice if we now handled these 4 digit dates as the standard they have become in the world.

I would propose adding a fourth optional parameter to the fromEuropeanDate, fromOrderedDate and fromUSADate methods of the datetime class that defaulted to 2, but could accept 4 to indicate the number of digits in the date part of the supplied argument. Alternatively some might argue that it would be neater and perhaps not break established code if these methods auto-detected the number of characters in the date and handled 2 or 4 character years apropriately.

At the same time, the datetime output methods europeanDate, orderedDate and USADate should accept a similar 2nd optional parameter to specify 2 or 4 digits. Again, to not break existing code it should default (sadly) to the now arcane 2 characters.

I suppose similar changes should happen to the date BIF, but I'm not sure how they would best be handled - it might be new date types, E4, O4 & U4 might be candidates, or an extra parameter for the year length, only allowed to be used for the E, O & U dates. Ideas?

Thanks, Jon

[Erich]

As an alternative to additional "xx4xx" methods, we might consider allowing a pattern, like from("DD.MM.YYY") or from("MMM DD YYYY").
I can never remember the exact format "European" or "Ordered" looks like and always have to look it up in the docs. Using a template which shows the requested format would make this easier.

[Jon Wolfers]

Hi Erich,

I agree. In fact a couple of weeks ago I worked up some code for a datetime subclass (written in Rexx) that can accept and produce from a format string. I was hoping to present this at the Rexxla symposium in September, but I can see that in the long run it would be better to have this included in the language.

The datetime class uses format strings in the native code to parse and produce strings, but I think that the internal format strings are not necesarily the standard that we should adopt and I tried to use the formats used by the ooDialog DateTimePicker class as they were already a published part of our documentation, but had to extend it. If you are interested in adding this to the datetime class and would like, I can send you my work.

Jon

[Erich]

Implemented dateparser.cls
Rick has committed revisions [r11907], [r11908], [r11911], and [r11912].
Solves the problem by adding generalized date parsing and formatting using a template.

A dateparser.cls fix was committed with revision [r12034].
A 'z' pattern fix for offset=0 committed with revision [r12122].

[Jon Wolfers]

I have re-opened this request.

Being able to handle 4 digit years is vital.

Whilst a dateparser class has been committed, it is not mentioned in the rexx reference nor programmer guide. Without documentation it cannot be used.