OK, I might have misunderstood the underscore at the beginning of _SDATE. I'd thought it was to indicate a RM-specific tag, but you seem to be saying it indicates a non-strict tag that may or may not be used by other programs too. As it happens, the programs that I've tried to import this .ged file to don't use sort dates. I'm not sure how they handle events that are newly entered, but for ones that are already in the file you can simply move them up and down the list to where you want them. Like Jon (message not quoted here) I use sort dates quite a lot, so having to get rid of them could be a significant task. However, I've thought of two possible ways round it: (a) the program that accepts _SDATE tags but ignores them creates a .ged file without the _SDATE tags, but I don't know whether it does anything else to the file which I'd prefer it not to (b) I came across a utility called GedPad which allows editing of a GEDCOM file, including the removal of all lines containing certain strings of characters. There may be other similar utilities too. Anyway, thanks for the replies, Arthur On 13/01/2015 20:31, Tom Holden wrote: > I don't think you have missed anything. _SDATE is a de facto standard > recognised by many other programs. I do not know if it originated with > RootsMagic. Even so, a well-designed import procedure would ignore > unrecognised GEDCOM tags and log them in its error log; it would not > trip up on them. Some software allows you to specify tags to be > ignored. Failing that, you can use a text editor such as NotePad++ to > do a global search and replace of lines containing _SDATE to overcome > your problem. > > Tom >