Skip to content

Siva - feature for timezone standardization in EventCard#4633

Merged
one-community merged 18 commits intodevelopmentfrom
feature/standardize-event-timezone-display
Apr 10, 2026
Merged

Siva - feature for timezone standardization in EventCard#4633
one-community merged 18 commits intodevelopmentfrom
feature/standardize-event-timezone-display

Conversation

@pavanputti
Copy link
Copy Markdown
Contributor

@pavanputti pavanputti commented Dec 27, 2025

Standardize Event Time Display Based on User Timezone on Event Cards

Description

Screenshot 2026-02-21 at 7 18 32 PM

Related PRs (if any):

This frontend PR is related to the development backend PR. To test this frontend PR, you need to checkout the development backend PR.

Main changes explained:

  • Created src/utils/timezoneUtils.js - Utility module with getUserTimezone(), convertToUserTimezone(), getTimezoneAbbreviation(), and formatDateTimeWithTimezone() functions for automatic timezone detection and conversion
  • Updated src/components/CommunityPortal/CPDashboard.jsx - Integrated timezone utilities to display event times in user's local timezone with abbreviations, added location placeholder handling
  • Updated src/components/CommunityPortal/Event/EventCard/EventCard.jsx - Integrated timezone conversion for event start/end times, improved date/time formatting with error handling
  • Updated src/components/CommunityPortal/CPDashboard.module.css - Improved alignment for event date/time and location icons, added styles for stacked date and time display
  • Code Quality - Replaced isNaN() with Number.isNaN(), added proper error handling, removed unnecessary comments

How to test:

  1. Check out branch and run npm install && npm run start:local
  2. Navigate to Community Portal → Dashboard
  3. Verify event times display with timezone abbreviations (e.g., "2:00 PM PST") and are converted to your local timezone
  4. Verify "Location TBD" appears for events without location
  5. Test in dark mode

Screenshots or videos of changes:

Before:

Screenshot 2026-01-25 at 3 25 33 AM

After:

Screenshot 2026-01-25 at 3 24 10 AM

- Added comment indicating where timezone conversion will be implemented
- This is the initial step for standardizing event time display based on user timezone
@netlify
Copy link
Copy Markdown

netlify bot commented Dec 27, 2025

Deploy Preview for highestgoodnetwork-dev ready!

Name Link
🔨 Latest commit 0aa4819
🔍 Latest deploy log https://app.netlify.com/projects/highestgoodnetwork-dev/deploys/69d88c81f87318000871903c
😎 Deploy Preview https://deploy-preview-4633--highestgoodnetwork-dev.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@pavanputti pavanputti added the do not review Do not review or look at code without full context label Dec 27, 2025
@pavanputti pavanputti force-pushed the feature/standardize-event-timezone-display branch from eff1ef7 to f67d61e Compare December 27, 2025 07:16
Phase 2 - Setup & Preparation:
- Created timezoneUtils.js file with skeleton functions
- Added placeholder functions: getUserTimezone, convertToUserTimezone, getTimezoneAbbreviation, formatDateTimeWithTimezone
- Added TODO comments explaining what each function will do
- No implementation yet - structure only
Phase 3 improvements:
- Implemented getUserTimezone() function using Intl.DateTimeFormat API
- Added exploration functions for testing date-fns-tz vs moment-timezone approaches
- Added comments in EventCard showing where timezone conversion will be implemented
- Added import comment (commented out) for future use
- Explored conversion options: moment-timezone (already in use) vs date-fns-tz (available)
- No full implementation yet - exploration phase only
Phase 4 improvements:
- Added moment-timezone import for testing conversion approaches
- Enhanced getUserTimezone() with validation and error handling
- Implemented test functions for both moment-timezone and date-fns-tz approaches
- Added bug fixes: null checks, validation, error handling
- Tested timezone detection across browsers (Chrome, Firefox, Safari, Edge)
- Documented testing results: decided to use moment-timezone for consistency
- Fixed issues found during testing: invalid date handling, null checks
- No full implementation yet - testing phase only
- Implemented complete timezone conversion using moment-timezone
- Added formatDateTimeWithTimezone function with timezone abbreviation
- Updated EventCard to use timezone utilities for time display
- Added location placeholder 'Location TBD' for empty locations
- Added error handling for date formatting
- Removed exploration functions from timezoneUtils
- Event times now display in user's local timezone with abbreviation (e.g., '2:00 PM PST')
- Updated timezoneUtils to use current date for timezone abbreviation (ensures all events show same PST/PDT)
- Fixed CPDashboard to use timezone utilities for consistent time display
- Improved event card alignment for date, time, and location with icons
- Fixed EventCard import path
- All events now show consistent timezone abbreviation across all cards
@pavanputti pavanputti changed the title feat: Add TODO comment for timezone standardization in EventCard Siva - feature for timezone standardization in EventCard Jan 25, 2026
@pavanputti pavanputti added Medium Priority and removed do not review Do not review or look at code without full context labels Jan 25, 2026
pavanputti and others added 2 commits February 7, 2026 01:34
…lay, resolve CPDashboard conflict

Co-authored-by: Cursor <cursoragent@cursor.com>
… display in eventsContent

Co-authored-by: Cursor <cursoragent@cursor.com>
@one-community one-community added High Priority - Please Review First This is an important PR we'd like to get merged as soon as possible and removed Medium Priority labels Mar 8, 2026
Copy link
Copy Markdown

@HemanthNidamanuru HemanthNidamanuru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

I tested this PR locally and everything works as expected. In dark mode, the date and time text are a bit hard to identify. Could you please check this?

Image Image

Copy link
Copy Markdown

@Anusha-Gali Anusha-Gali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Siva,

I have reviewed your PR locally and have identified the below issues;

  • I do not see any mention / example of "Location TBD" in any events
  • as you can see below the before and after, how is that the same time in two different events is converted to different times in EDT
    Before
Image **After** Image
  • cannot see the date and time clearly in dark mode
Image

@pavanputti
Copy link
Copy Markdown
Contributor Author

Hi Siva,

I have reviewed your PR locally and have identified the below issues;

  • I do not see any mention / example of "Location TBD" in any events
  • as you can see below the before and after, how is that the same time in two different events is converted to different times in EDT
    Before

Image After Image

  • cannot see the date and time clearly in dark mode
Image

Hi @Anusha-Gali ,
Why the time was wrong on development (before)
On the development branch, the time shown comes from the event’s date field (e.g. 2025-03-01T08:00:00.000Z), which is 08:00 UTC. In Eastern that becomes 3:00 AM, so you see “3:00 AM.” The actual event time is in startTime (e.g. 5:00 PM Pacific = 8:00 PM EDT). Because development uses date instead of startTime for the time, it shows the wrong time.
After the changes in this branch
We use startTime for the displayed time and convert it to the user’s timezone with a label (e.g. “8:00 PM EDT”). So the time now matches the real event time instead of the date value.
Location TBD
It only shows when location is empty, null, or "TBD". Right now all events have a location set, so you don’t see it. To verify, set one event’s location to "" in the DB and reload.
Dark mode
I’ve fixed dark mode so date, time, location, and organizer are readable on the dark background.
Thanks for reviewing.

@pavanputti
Copy link
Copy Markdown
Contributor Author

Hi,

I tested this PR locally and everything works as expected. In dark mode, the date and time text are a bit hard to identify. Could you please check this?

Image Image

Hi @HemanthNidamanuru
Thank you for testing the PR and for pointing this out. I’ve updated the dark mode styles to improve the visibility of the date and time text. Could you please check the latest changes when you get a chance? Thanks!

Copy link
Copy Markdown

@rohanrastogi311 rohanrastogi311 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Siva,

Well done with this implementation.

Image

Anusha-Gali
Anusha-Gali previously approved these changes Mar 17, 2026
Copy link
Copy Markdown

@Anusha-Gali Anusha-Gali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Siva,

Thanks for the update on location and for making the updates. I have re-reviewed your PR locally and it works as per requirement.

Image Image

}
};

const formatDateTime = (eventDate, timeString) => {
Copy link
Copy Markdown

@naznin07 naznin07 Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical bug in formatDateTime.

PR # 4633

Copy link
Copy Markdown

@Vishnu10-hub Vishnu10-hub left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

I have reviewed the implementation locally, and everything is working perfectly as expected. Great job!

Image

…e-timezone-conversion

- toFullEventDatetime was calling moment(eventDate) which parsed the date
  in the local machine timezone. formatDateTimeWithTimezone then called
  .tz(userTimezone) on this already-offset value, causing double conversion
  and producing different (wrong) times across different machines.

- Fixed by switching to moment.utc(eventDate) and returning dateM.toISOString()
  so the combined datetime is strictly UTC. The single .tz() call in
  formatDateTimeWithTimezone then performs the correct, consistent conversion.

- Tightened looksLikeFullDatetime heuristic to only match strings containing 'T'
  (strict ISO 8601). The previous check (s.includes('-') && s.length > 12) falsely
  matched time-only strings with offsets (e.g. '17:00-05:00'), bypassing the
  date-anchoring logic entirely.

- Added eventDate guard in EventCard formatDateTime: if eventDate is missing,
  return 'Date not set' instead of silently falling back to local-time parsing.

Fixes reviewer feedback from naznin07 on PR #4633.
@pavanputti pavanputti dismissed stale reviews from Anusha-Gali and rohanrastogi311 via 35f7c07 April 10, 2026 03:56
All four catch blocks were flagged by SonarQube rule 'Handle this
exception or don't catch it at all' (CWE error-handling):

- fetchEvents catch: err was caught but never referenced — added
  console.error so the error variable is explicitly used before
  setting the user-facing error message.

- formatDate catch: renamed 'error' -> 'err' for consistency and
  confirmed it is passed to console.error.

- formatTime catch: same rename as formatDate.

- parseEventDate catch: already used err in console.error, improved
  the message to be more descriptive ('Error parsing event date').

All blocks retain their graceful-degradation behaviour (fallback
return values) so no functional change to the UI.
@sonarqubecloud
Copy link
Copy Markdown

@one-community
Copy link
Copy Markdown
Member

Thank you all, merging!

@one-community one-community merged commit d8ec064 into development Apr 10, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

High Priority - Please Review First This is an important PR we'd like to get merged as soon as possible

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants