Fix Android date picker ignoring past (and future) dates on workout/cardio logging

[Copilot]

On Android, DateTimePickerAndroid.open fires onChange twice after a user confirms a date: once with type: 'set' (the selected date) and once with type: 'dismissed' (the original value — today). Because the handlers ignored the event entirely, the second call silently overwrote the user's selection with today's date.

Changes

• InputWorkout.tsx / CardioTracker.tsx — all four date/time change handlers (onAddDateChange, onAddTimeChange, onEditDateChange, onEditTimeChange) now guard state updates on event.type === 'set':

// Before
const onAddDateChange = (_event: DateTimePickerEvent, date?: Date) => {
    if (date) { setSelectedDateTime(...) }
};

// After
const onAddDateChange = (event: DateTimePickerEvent, date?: Date) => {
    if (event.type === 'set' && date) { setSelectedDateTime(...) }
};

The same pattern was applied to both the workout and cardio trackers, since both shared the same bug.

Original prompt

Investigate and resolve the issue in the workout logging section where changing the workout date to a past date is ignored and the current date is logged instead. Specifically:

1. Determine why the current date is being used in place of past dates.
2. Fix the bug to ensure that the user-selected date (including past dates) is accurately saved and logged into the database.
3. Test the fix with various dates including past, present, and future dates to ensure consistent and correct functionality.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: There is a bug in the workout logging section in the app. When a user attempts to change the date of a workout to a date in the past (for example 4/2/2026), it instead uses the current date and logs that into the database.

Figure out what is causing this bug, and create a pull request on main for review.

Assistant: A pull request is being created to resolve the workout logging issue where past dates are ignored, logging the current date instead. I'll notify you upon completion.

This pull request was created from Copilot chat.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
bulktech	Ready	Preview, Comment	Apr 28, 2026 4:17am

[NeonGems65]

@copilot Everything works perfectly on the local development server (when there's nothing on it). But when I edit the date on the already pre-existing database, it does not change.

Is there a way to run the app connected to my Render database?

[Copilot]

@copilot Everything works perfectly on the local development server (when there's nothing on it). But when I edit the date on the already pre-existing database, it does not change.

Is there a way ...

Yes — the app already supports this via environment variables. Here's how:

Connect the Expo app to your Render server

Create my-expo-app/.env (copy from .env.example) and set:

EXPO_PUBLIC_API_URL=https://<your-render-service>.onrender.com

Then restart expo start. The getApiBaseUrl() helper reads this value and will point every API call at your Render backend instead of localhost.

Connect the local server to your Render (Neon) database

If you also want to run the server locally but have it talk to the Render/Neon database, create server/.env and set:

DATABASE_URL=******host:5432/dbname
NODE_ENV=production

The db.js pool creation already prefers DATABASE_URL when it's present, and sets ssl: { rejectUnauthorized: false } for production.

Once the app is hitting the same Render backend (and thus the same database), the date-edit fix should apply to pre-existing rows too — the PUT endpoint has always accepted the created_at from the request body and the client always sends editDateTime.toISOString().