plot no longer accepts date/time data in pygmt 0.14

[eelcodoornbos]

The following script works in 0.13 (and before), but fails to plot anything in 0.14 with the message pygmt-session [WARNING]: Unable to parse 5 longitude strings:

import pygmt
import pandas as pd
xdata = [pd.to_datetime("2024-12-01"),
         pd.to_datetime("2024-12-15"),
         pd.to_datetime("2024-12-31"),
         pd.to_datetime("2025-01-15"),
         pd.to_datetime("2025-02-01")]
ydata = [0.1, 0.2, 0.5, 0.7, 0.4]
fig = pygmt.Figure()
fig.basemap(projection='X10cT/5c', region=["2024-12-01T", "2025-02-01T", 0, 1], frame=True)
fig.plot(x=xdata, y=ydata)
fig.show()

[weiji14]

Hmm yes, I can reproduce this on PyGMT v0.14.0. We'll need to check what changes caused this regression. In the meantime, could you put your list of pandas.Timestamp objects into a pandas.DatetimeIndex (following https://www.pygmt.org/v0.14.0/tutorials/advanced/date_time_charts.html#using-pandas-date-range) like so:

xdata = pd.DatetimeIndex(
    data=[
        pd.to_datetime("2024-12-01"),
        pd.to_datetime("2024-12-15"),
        pd.to_datetime("2024-12-31"),
        pd.to_datetime("2025-01-15"),
        pd.to_datetime("2025-02-01"),
    ]
)
ydata = [0.1, 0.2, 0.5, 0.7, 0.4]

fig = pygmt.Figure()
fig.basemap(
    projection="X10cT/5c", region=["2024-12-01T", "2025-02-01T", 0, 1], frame=True
)
fig.plot(x=xdata, y=ydata, verbose=True)
fig.show()

produces

[yvonnefroehlich]

@eelcodoornbos Thanks for reporting this!
Just checked our Tutorial Plotting datetime charts. There we also have this warning when using datetime.datetime (not for datetime.date) in v0.14.0 (please see https://www.pygmt.org/v0.14.0/tutorials/advanced/date_time_charts.html#using-python-s-datetime the second example).

I do not remember I saw this warning, when making two minor changes to this tutorial (https://github.com/GenericMappingTools/pygmt/pull/3664/files, December 2).

[weiji14]

So the xdata array get converted into a numpy array of type np.str_ instead of an np.datetime64 dtype, and is parsed incorrectly as GMT_TEXT instead of GMT_DATETIME here:

pygmt/pygmt/clib/session.py

Lines 942 to 947 in 2a84b5e

	# 1-D arrays can be numeric or text, 2-D arrays can only be numeric.
	valid_dtypes = DTYPES if ndim == 1 else DTYPES_NUMERIC
	if (dtype := array.dtype.type) not in valid_dtypes:
	msg = f"Unsupported numpy data type '{dtype}'."
	raise GMTInvalidInput(msg)
	return self[DTYPES[dtype]]

These lines were most recently changed in #3563, but I don't think the bug was caused by that PR, probably somewhere else when we were doing the refactoring. Using the pandas.DatetimeIndex workaround above would correctly turn the array into a np.datetime64 type. The warning about Unable to parse 5 longitude strings is indicating that strings like '2024-12-01 00:00:00', '2024-12-15 00:00:00', ... (note the space in between the date and time) are being passed into pygmt's clib functions.

@seisman, should we revise the logic in that pygmt.clib.Session._check_dtype_and_dim method, or do you think it should be done elsewhere?

[seisman]

xdata is a list of Timestamp objects, and it can't be converted to the numpy.datetime64 dtype by the np.ascontiguousarray function:

>>> np.ascontiguousarray(xdata)
array([Timestamp('2024-12-01 00:00:00'), Timestamp('2024-12-15 00:00:00'),
       Timestamp('2024-12-31 00:00:00'), Timestamp('2025-01-15 00:00:00'),
       Timestamp('2025-02-01 00:00:00')], dtype=object)

Then, it's converted to np.str_ by the following lines:

pygmt/pygmt/clib/conversion.py

Lines 197 to 200 in c7198e6

	# Check if a np.object_ array can be converted to np.str_.
	if array.dtype == np.object_:
	with contextlib.suppress(TypeError, ValueError):
	return np.ascontiguousarray(array, dtype=np.str_)

The fix should be easy and should be done in the _to_numpy function.

Actually, I already had a branch to_numpy/datetime(commit 949b124) which can fix the "bug" (didn't realize the existence of the bug when I created the branch).

I can submit a PR for this branch, but I feel it would be better to have PRs #3670, #3687 merged first to ensure that the to_numpy/datetime branch has no side-effects.