1st, you could store the _gwDateList as an Event Attribute… the label indicating that the value contains information in GeneWeb format’s data structure. (The label could be named in another way. It just needs to help you associate the attribute’s value with the date list in the .gw format/tag within the format.)
2nd, individually evaluate the list of .gw dates to find a minimum and maximum to create a ”between <minimum> and <maximum>” date… although a ’between’ is not a great equivalent to the .gw list of dates, it IS parsable with the existing Gramps DateHandlers.
(Such a _gwDateList custom attribute has the potential of writing a .gw file that is symetrical in your export add-on. Although you might want to add a comment to the .gw attribute of the evaluated ”between” date. If unchanged since import, that evaluation can be discarded during export. If changed, you would have to decide what to do.)
Eventually, you might write a DateList Gramps DateHandler & a utility that converts _gwDateList attributes into that newly supported Gramps date format.
I agree with @Mattkmmr, enter any alternate birth dates as a separate event with the Type Alternate Birth. This type does not currently exist, but you can type the entry into the drop-down list.
Gramps will only act on the one main Birth event so use this for your best supported (sourced) information. Not all reports will use the alternate information so these alternate events will only show in reports that will display a list of all of a person’s events.
Have to disagree. This approach arbitrarily assigns greater weight to the first date when that weight doesn’t exist in the original file. (Although that is still better than discarding the 2nd date!)
‘Between’ maintains the uncertainty and equal weight. The GEDCOM import preserves the original context in a Note containing the unparsable data tag. But while the sort-Notes-by-date simulates a ”import failure” log, Notes invite careless editing.
So storing the unmodified & unsupported record in an Attribute offers stable future options should the date handling evolve.
To clarify my previous comment on how I’d handle two or more alternative dates for one event:
I’d record several alternative event dates by creating one event where the event date is a date range which encloses all alternative dates. All alternative dates should be added as attributes and their sources as citations/sources. Maybe a tag “event with alternative dates” would also make sense.
I’d avoid creating several events for alternative dates, because yes for birth events it is obvious that a person was just born once (same for death), but for all other event types it could be either the one event with two alternative dates or two seperate events. It could also happen that you have several events of a certain type where each event has several alternative dates. A complex situation like that could make it impossible to match the correlating alternative dates from different events afterwards.