This paper describes a pollen records dataset, including explanations and descriptions of the dating methods involved in creating the dataset. The global coverage of this dataset is impressive and the presentation of the manuscript is quite good. There are some minor issues with accessing the data, and some considerable issues with the associated code attached to this paper. While the general shape of the manuscript is good, I encourage a stronger focus on the data itself. These papers are most useful as upfront descriptions of data which requires a slightly different structure than a research articles. Specifically, I would recommend reshaping the intro and the abstract especially to put the data at the forefront, i.e. lead off with statements declaring the dataset, and what it is--for example, putting the name and description of the dataset as the first sentence in both. 

The description of dating methods needs to be expanded briefly, including explicitly defining terms such as "reservoir effect" or clarifying what "insufficient carbon" is. Lead dating is lacking description of methodology as is luminescence. Please also include how these dating methods add to measurement uncertainty in the data. Are uncertainties included?

DATA (PANGAEA) - this dataset looks to be in good shape and is well-documented when i look at the site the DOI takes me too. When I download the .tab delimited file though, it is really tough to parse. Is there a reason this is in .tab format? A comma separated (.csv format) would be more universal, but I defer to the authors here if there is some subfield specific reason .tab format is better. Admittedly though, I found it difficult to work with this format when downloaded directly. The html web formatted table was easy enough to read. 

CODE

The R code that accompanies this data paper and package is highly problematic from an open-code, data sharing perspective. It is formatted for personal use and not up to community standards. The main issue is the beginning call of `rm(list=ls())` This command cleans out and removes all entries in a user's memory and R workspace. Jenny Bryan wrote an excellent piece on why this snippet of code does not work for project based workflows (https://www.tidyverse.org/blog/2017/12/workflow-vs-script/) 

The major problem with this becomes apparent a couple of lines down when there are 'fixed' calls to data files that do not exist anywhere--nor can I find them. So running the code is impossible. 

I would recommend using URLs for those code calls so that when the code is run those data are imported directly from their fixed, online locations. The fixed DOIs from where your data are stored could be used. 

This area of this manuscript/data must be addressed. Additionally, the code is commented adequately, and follows a fairly good syntax, formatting structure. I applaud that. The repo in GitHub though has no readme and no documentation there. That really needs to be added. You could include a lot of what is in this paper, in the data metadata write up elsewhere. I would also encourage including a copy of this manuscript as well as copious amounts of links. 

A big ask, which I think would take this next level, is to include a vignette or markdown file showing how to work with his data that includes a small, worked example. 

In the current state, I cannot run the code, which gives me pause on my recommendation. 

Specific comments:

line 44 - the phrase "calibrated and uncalibrated" is confusing. 

line 65-75 - it would be advisable to have these variables in a table with further descriptions.

79-80 - repeated use of references to "most common"

Section 2.3.1. - for this type of paper, consider leading this section off with what you have as your final sentence, then describing it. "...all age relationships in our data set are constructed using Bacon..." then describe why and what and how. 

line 139-141 - where did the latest calibration curves come from? this sentence lacks context. 

Section 2.3.4 consider laying this section out using bullets or with some kind of work design flow infographic. 

* just a note format your units with super- and subscripts, not / notation

lines 167 -... Consider again bullets or something instead of a numbered list inside of a paragraph. 

Most analyses using Neotoma or other archived pollen data are dependent, at least to some extent, on the chronologies. The available chronologies have variable quality: some record have an uncalibrated chronology, others have a Bayesian chronology. In many cases the uncertainty on the chronology is not available, or if it is, just the upper and lower credibility interval. To synthesise pollen data from several datasets, it may be necessary to harmonised the age-depth models, a huge amount of work. Once such harmonisation is presented in this current manuscript.

As far as I can tell, the chronologies are not archived, but instead the metadata needed to make the chronologies. This is probably a good idea as it encourages the user to check the parameters.

One important result is that "95.4% of records could be improved ". However, it is unclear what objective criteria were used to determine whether the new model represented an improvement. The criteria need to be explicitly stated. 

The metadata and code are available on github (Zenodo.org would be preferable for the final version).

The data are arranged in wide format, with a set of columns for each date. This is not the ideal way to arrange the data, as it makes the code much more complicated to deal with this structure, and will need extra extra columns adding in the future to cope with new sites. A better setup would be to have the data in long format, perhaps in multiple files that can be joined by the dataset ID. 

At present, datasets are marked as being marine or otherwise. At least in principle, there could be datasets where some dates are on marine fossils, and others on terrestrial macrofossils. Marine should be a property of the date, not the core.

Setting a constant reservoir age for a core without error seems risky to me. Do you check these are only occuring with bulk dates, as there should not normally be a problem with terrestrial macrofossils. 

The code is presented in a single script. This is fine if someone wants to make chronologies for all datasets, but often people will want to run a subset of the sites, and may find the script difficult to use. Breaking the script into functions than each do one task, perhaps compiled into a small package with help files and other documentation, would make the product more useful.

The code includes fixes for issues the authors found in Neotoma. Please report these issues, and make sure the code to fix them (e.g. line 187) will work safely when the error is fixed.

Figures 4-6. The x-axis, labelled 0-1, 1-2 etc, is rather cluttered and difficult to read. Please consider other ways to label them. The relative lack of outliers in the pre-LGM sediment is interesting, but probably represents over-fitting the models to sparse data.

Figure 7 has a minuscule font: I need to view it at 200% before I can read it. No need to repeat the legend four time - once is enough and leaves more space for everything else.

Minor points:

Line 202 "with  fewer  than 2" Maybe rewrite as "only one" for clarity. Consideration should be given as to the minimal number of dates that can give a good chronology - I would be cautious using a model based on only two dates.

Review of ESSD-2021-212 entitled: ‚Harmonized chronologies of a global late Quaternary pollen dataset (LegacyAge 1.0)‘ by Chenzhi Li et al.

In this work the authors present their attempt to harmonize mainly radiocarbon-based chronologies of continental climate records. The harmonisation is with respect of age-model software usage, calibration curve usage, which is a very valuable task. Furthermore, harmonisation is performed with respect to parameters used for the age-depth modelling software. As far as I understand, the authors use the age-modelling software Bacon for age-depth modelling of a huge quantity of records. Before modelling, the cores were manually evaluated in terms of complications, such as radiocarbon reservoir effects, water lines, etc.

While I appreciate their approach, I think there are some things to be improved before suggesting this piece of work for publication. Usually, such a data set and code is generated to be used. Unfortunately, I cannot find any description or manual, how to access the age-depth models. Nor is it possible for me to run the R-script. I admit, I am a R-noob, but I think, application should be properly described with at least a short manual for users with some R-experience (or even noobs). This does not have to come with this publication, but it should at least appear on their github space next to the R-file.

Furthermore, I am not able to find age-depth profiles on their provided Pangaea-page. I thought the authors did all their work (handling reservoir effects, water lines, deciding for the best thicknesses to be applied, …) in order to provide a homogeneous age-depth data set. And according to their paper, they spend a lot of efforts to evaluate the datings etc of all records. It would be a pity, if they would not share this. Or is the user supposed to start from scratch again? Even if it ‘only’ means to run their script – if I understand the code structure correctly, the user has to run all of their thousands of records, even if the user is only interested in one or two records. Especially, as this means to run ‘millions of MCMC iterations’ (line 120) which cannot be that cheap as even admitted by the authors: “… it needs much supervision and computing power” (line 122). Why not provide all age depth models (including uncertainties) in addition to all meta data and code? Or at least enable the user to only calculate the age-depth models of the records they are interested in?

Another critical question is about the final age models. As I cannot find them, nor are able to run the R script, I have to ask: Which depths intervals do you choose to save for the homogenised age-depth models? In the paper you mention the effect of choosing different levels or depth intervals on the goodness of the model data and that some are better suited than others. However, I even wonder, why a user should care about having the age-depth relationship on a fixed sampling interval? If I want to work with other paleoclimate data, I am interested in an age-depth model, which provides dates at depth, where the proxies were measured. Is the output of your script arranged in a way, that this could be easily accessed? Unfortunately, this is not mentioned in the paper. Or do you expect the user to apply some (more or less) fancy interpolation algorithm to assign ages for the proxy depths?

In addition I have some more issues with respect of minor and technical aspects:

L16 and 46: Please elaborate a bit more on what you understand by ‘harmonized chronology’ already this early in the manuscript. I am pretty, sure, that different people understand different things under this term. I mean later in the paper it becomes clear, what you understand by this term, but I think it is worth to highlight this already in the beginning of your work.

L27-28: This sentence needs more explanations. Maybe not here in the abstract, but below in the according text passages. Please find a more detailed comment below.

L69-74: You provide quite some detailed information on metadata, which I appreciate a lot. However, I doubt that putting those data all in one file is the best option. I agree with referee 2 to splitting this file up in several is maybe more appropriate and easier to handle. At least keep this in mind for any potential future improvements.

L155: ‘acc.mean’ is possibly ‘acc.rate’?

L158: ‘We tested six thicknesses (2.5 cm, 5 cm, 10 cm, 30 sections, 60 sections, and 120 sections) …’. I am not very familiar with Bacon. But, why would you want to test those 6 sampling intervals? I mean, the proxies of the cores were measured at specific depths - wouldn't it be more suitable to only interpolate to those depths, where proxy data exist? Actually, this is the data, I would be interested in. But it seems, that this is missing completely. What do you suggest to finally obtain the ages at those depths?

L159: ‘artificial surface age’, Why would it be necessary to add an artificial date? I don't know if I understand the concept of adding an artificial date correctly. Stating things like this sounds very arbitrary. Or do you mean you added another age-constraint due to the assumption that the core sedimentation was active until core recovery? And that the additional age constraint is the year of core recovery? If yes, please consider to specify accordingly.

L159: ’generating 12 age models for each core’. Just to make sure I understand correctly. Your code provides 12 age-depth models for one core. Are all provided in output files?

L170:  I think, C exchange between dissolved C-species in water and atmospheric CO2 is not responsible for ‘too old radiocarbon dates’. Instead, this process counter balances to some degree the effect of the arguments listed earlier in this sentence.

L171-173: For some records you added your evaluation of reservoir effects. I appreciate this a lot, but I think it is worth to add a column in your metadata file and mark those records. This would allow a better transparency about what is your evaluation and which information came from the original studies.

L184: For the use of radiocarbon dates for modelling purposes, you followed ‘in most cases the suggestions in the original publications’. Please consider – again for a better transparency - to provide information (maybe in your metadata file), for which records you did not follow the suggestions of the original publications.

L189-191: ‘For each record, 12 age models were visually assessed. Preference was given to models that fitted the dates well and with small uncertainties when choosing the ‘best’ model for each record (Blaauw and Christen, 2011; Blaauw et al., 2018).’. This is a lot of work for thousands of records. You are sure, that you did this all correctly for this large amount of records? I wonder if it would have been more objective to apply a short statistical test on this. I mean, most likely a simple least square test between age model and ages of dated depths would do a better and faster job. Also the ‘small uncertainty’ argument would be most likely more precise and faster to obtain, when calculating the mean uncertainty instead relying on visual assessment.

L203: Who did the evaluation about what a reliable date is? You or the original authors? I can imagine, that this is a difficult task, especially for cores from others.

L247-248: ‘where original chronologies outperformed LegacyAge 1.0, …’ How do you know, which model approach outperforms the other? How can you measure or evaluate this? Do you have knowledge of the ‘true sedimentation history’ of all those records to be able to judge this? Which one do you choose from your 12 ones/core? I think it is very crucial to provide more details on this issue. Or, in case you wanted to express a different thing with this expression, please consider to rephrase this sentence.

Fig. 7: Please provide information about which of the twelve generated age-depth models for each record you show here! Would it be possible to show one additional age-depth realisation, which fits less good with the measured ages. Only to give the reader an idea about the effects of the choice of depths intervals.