Feature request: Editable date and time for Measures in Calendar

[Richard Köhler]

Hello GoldenCheetah developers and fellow cyclicts,

I would like to suggest a small improvement to the Calendar’s Add/Edit Measure dialog.

When I add a Measure retrospectively from the Calendar chart in Trends perspective, GoldenCheetah correctly uses the selected date but combines it with the current time. For example, entering a measure for July 17 at 13:42 today creates a timestamp of July 17, 13:42.

This can cause a problem when the measure represents the athlete’s condition for the whole day, such as weigth, night HRV, fatigue etc.. Activities recorded earlier that day may not take the measure into account because their timestamps precede it.

Would it be possible to:

make both the date and time editable in the Add/Edit Measure dialog;

preserve the existing timestamp when editing a measure;

correctly replace the original record if its timestamp is changed, rather than creating a duplicate?

Alternatively, simply defaulting Calendar-created measures to 00:00 would already solve the main issue for daily body and wellness data.

The Athlete Settings → Measures dialog already allows a date and time to be selected when creating a new entry, so similar functionality in the Calendar would make retrospective entry much more convenient.

I am currently using GoldenCheetah V3.8.-DEV2605, build id 5012 on macOS 26.5.2.

Thank you for considering this improvement and for your work on GoldenCheetah.

Best regards,

Richard

[Ale Martinez]

Hi Richard, this is something I miss sometimes but I am not sure about full edit which is more complex and we are near release.

I tried a simple modification to use default start hour, which is configurable, for add measure:

diff --git a/src/Gui/Calendar.cpp b/src/Gui/Calendar.cpp
index 47c3060c2..4515eee2a 100644
--- a/src/Gui/Calendar.cpp
+++ b/src/Gui/Calendar.cpp
@@ -1601,6 +1601,7 @@ void
 CalendarDayView::setStartHour
 (int hour)
 {
+    defaultStartHour = hour;
     dayTable->setStartHour(hour);
 }

@@ -1739,7 +1740,7 @@ CalendarDayView::updateMeasures
         if (buttonType == 0) {
             QPushButton *addButton = new QPushButton(tr("Add Measure"));
             connect(addButton, &QPushButton::clicked, this, [this, date, measuresGroup]() {
-                if (measureDialog(QDateTime(date, QTime::currentTime()), measuresGroup, false)) {
+                if (measureDialog(QDateTime(date, QTime(defaultStartHour, 0, 0)), measuresGroup, false)) {
                     QTimer::singleShot(0, this, [this, date]() {
                         updateMeasures(date);
                     });
diff --git a/src/Gui/Calendar.h b/src/Gui/Calendar.h
index ff0cbe281..0a9c0d644 100644
--- a/src/Gui/Calendar.h
+++ b/src/Gui/Calendar.h
@@ -297,6 +297,7 @@ private:
     CalendarOverview *dayDateSelector;
     QTabWidget *measureTabs;
     CalendarDayTable *dayTable;
+    int defaultStartHour;

     bool measureDialog(const QDateTime &when, MeasuresGroup * const measuresGroup, bool update);

     void updateMeasures(const QDate &date); 

It works better than current hour or midnight for my use case and I could include the change for the next build, but I am not sure if Joachim -who developed the new Calendar- is Ok with this change.

Cheers, Ale.

[Joachim Kohlhammer]

Hi Ale,

your change definitely works better than the status quo, I have the same issue when adding metrics. But maybe we could refine it a little further: My wake up time is usually between 6:00 and 7:00 whereas my calendar starts at 10:00 - for improved scaling. What do you think about adding a wake up time to the calendars configuration to use as default for metrics? If you agree I will create a PR.

Cheers, Joachim

[Joachim Kohlhammer]

Started a PR: https://github.com/GoldenCheetah/GoldenCheetah/pull/4903

[Ale Martinez]

El viernes, 24 de julio de 2026 a la(s) 7:12:07 a.m. UTC-3, tiefgara...@gmail.com escribió:

Started a PR: https://github.com/GoldenCheetah/GoldenCheetah/pull/4903

Thanks Joachim, the PR is merged and it will be included in the next build. 

[Ale Martinez]

Latest snapshot builds, which will become v3.8-RC1 once I complete the release notes, are available from https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot

[Joachim Kohlhammer]

Hi Ale, sounds awesome, I am looking so much forward to 3.8.

In the meantime I am investigating a crash of GoldenCheetah when fast switching between activities and having the attached python chart active. It seems to be some race condition in seasonIntervals (and similar methods):

(gdb) backtrace

#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44

#1 0x00007f92050a629f in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89

#2 0x00007f920504f842 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26

#3 0x00007f92050374b2 in __GI_abort () at ./stdlib/abort.c:77

#4 0x00007f9205037424 in __assert_fail_base (fmt=<optimized out>, assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=0x55a45d7b3c38 "void PyList_SET_ITEM(PyObject*, Py_ssize_t, PyObject*)") at ./assert/assert.c:118

#5 0x000055a45caa3ac2 in PyList_SET_ITEM.part.0 ()

#6 0x000055a45caa3ae6 in PyList_SET_ITEM.cold ()

#7 0x000055a45cbfe7e8 in Bindings::seasonIntervals(DateRange, QString) const ()

#8 0x000055a45cbff543 in Bindings::seasonIntervals(QString, bool) const ()

#9 0x000055a45cbe8598 in meth_Bindings_seasonIntervals ()

#10 0x00007f9213571d62 in ??? () at /usr/lib/x86_64-linux-gnu/libpython3.13.so.1.0

#11 0x00007f92135158da in _PyObject_MakeTpCall () at /usr/lib/x86_64-linux-gnu/libpython3.13.so.1.0

#...

I hope to  be able to propose a PR by end of today

Cheers, Joachim

[Ale Martinez]

El domingo, 26 de julio de 2026 a la(s) 4:09:21 a.m. UTC-3, tiefgara...@gmail.com escribió:

Hi Ale, sounds awesome, I am looking so much forward to 3.8.

In the meantime I am investigating a crash of GoldenCheetah when fast switching between activities and having the attached python chart active. It seems to be some race condition in seasonIntervals (and similar methods):

(gdb) backtrace

#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44

#1 0x00007f92050a629f in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89

#2 0x00007f920504f842 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26

#3 0x00007f92050374b2 in __GI_abort () at ./stdlib/abort.c:77

#4 0x00007f9205037424 in __assert_fail_base (fmt=<optimized out>, assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=0x55a45d7b3c38 "void PyList_SET_ITEM(PyObject*, Py_ssize_t, PyObject*)") at ./assert/assert.c:118

#5 0x000055a45caa3ac2 in PyList_SET_ITEM.part.0 ()

#6 0x000055a45caa3ae6 in PyList_SET_ITEM.cold ()

#7 0x000055a45cbfe7e8 in Bindings::seasonIntervals(DateRange, QString) const ()

#8 0x000055a45cbff543 in Bindings::seasonIntervals(QString, bool) const ()

#9 0x000055a45cbe8598 in meth_Bindings_seasonIntervals ()

#10 0x00007f9213571d62 in ??? () at /usr/lib/x86_64-linux-gnu/libpython3.13.so.1.0

#11 0x00007f92135158da in _PyObject_MakeTpCall () at /usr/lib/x86_64-linux-gnu/libpython3.13.so.1.0

#...

I hope to  be able to propose a PR by end of today

Joachim's fix for the crash above is included in latest snapshot builds: https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot, this is the only difference with v3.8-RC1 for anyone willing to test, feedback is welcome.