Replace Formatting with Format

[imreddyTeja]

Purpose

Formatter.jl is no longer maintained. This PR replaces its usage with Format.jl
Closes #937

To-do

Content

---

• I have read and checked the items on the review checklist.

[juliasloan25]

Thanks Teja! I wonder if we even need to keep the Format.jl dependency. It looks like it's only used in one place for met_drivers_FLUXNET.jl and the corresponding lib/ClimaLandSimulations file make_drivers.jl.

Dates.jl also has a function Dates.format that might do what we need. Or if we're only keeping Format around for one function, we could potentially implement it ourselves. Maybe @AlexisRenchon or @Espeer5 will know if we added Format.jl just for the two calls linked above?

[Espeer5]

Thanks Teja! I wonder if we even need to keep the Format.jl dependency. It looks like it's only used in one place for met_drivers_FLUXNET.jl and the corresponding lib/ClimaLandSimulations file make_drivers.jl.

Dates.jl also has a function Dates.format that might do what we need. Or if we're only keeping Format around for one function, we could potentially implement it ourselves. Maybe @AlexisRenchon or @Espeer5 will know if we added Format.jl just for the two calls linked above?

Hmm it's been a while since I wrote this. I think the problem was that the data would automatically be read in as a number and formatted as "##e##" or something like this... I will make a separate issue to work on this as I also want to generalize these scripts to read a specified start date so that the ClimaArtifact for the fluxtower data can be updated to include the full data sets. In the process I will see if I can remove the dependency on Format.

[juliasloan25]

Thanks Teja! I wonder if we even need to keep the Format.jl dependency. It looks like it's only used in one place for met_drivers_FLUXNET.jl and the corresponding lib/ClimaLandSimulations file make_drivers.jl.
Dates.jl also has a function Dates.format that might do what we need. Or if we're only keeping Format around for one function, we could potentially implement it ourselves. Maybe @AlexisRenchon or @Espeer5 will know if we added Format.jl just for the two calls linked above?

Hmm it's been a while since I wrote this. I think the problem was that the data would automatically be read in as a number and formatted as "##e##" or something like this... I will make a separate issue to work on this as I also want to generalize these scripts to read a specified start date so that the ClimaArtifact for the fluxtower data can be updated to include the full data sets. In the process I will see if I can remove the dependency on Format.

That sounds like a good plan! In the meantime, we can go ahead with this PR to at least remove the docs warning about Formatting.jl

[imreddyTeja]

Hmm it's been a while since I wrote this. I think the problem was that the data would automatically be read in as a number and formatted as "##e##" or something like this... I will make a separate issue to work on this as I also want to generalize these scripts to read a specified start date so that the ClimaArtifact for the fluxtower data can be updated to include the full data sets. In the process I will see if I can remove the dependency on Format.

I briefly looked into it when replacing Formatting with Format. It seems like format is used because to parse something in the yyyymmddHHMM form, Dates needs a string. The string representation of large floats in is scientific notation. I think we could get around this by converting the dates that are read in to ints before converting them to strings.

For example:

DateTime.(format.(driver_data[2:end, 1]), "yyyymmddHHMM")

could be

DateTime.(string.(Int.(driver_data[2:end, 1])), "yyyymmddHHMM")

This should be fine because the original would still error if a non-whole number is given.