Skip to content

update workflow date formatting to use IST timezone and 24-hour format#1132

Open
abhishekkumar004-lgtm wants to merge 1 commit intomainfrom
workflow_timeformat_fix
Open

update workflow date formatting to use IST timezone and 24-hour format#1132
abhishekkumar004-lgtm wants to merge 1 commit intomainfrom
workflow_timeformat_fix

Conversation

@abhishekkumar004-lgtm
Copy link

update workflow date formatting to use IST timezone and 24-hour format

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @abhishekkumar004-lgtm, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request standardizes the date and time displays throughout the application's workflow features. The changes ensure that all timestamps, including those for workflow creation, execution, and completion, consistently reflect the Indian Standard Time (IST) and are presented in a clear 24-hour format. This improves clarity and consistency for users, particularly those operating in or concerned with the IST timezone.

Highlights

  • Standardized Date Formatting: All date and time displays across various workflow components have been updated to use a consistent format.
  • Indian Standard Time (IST) Implementation: Dates and times are now explicitly formatted to reflect the 'Asia/Kolkata' timezone.
  • 24-Hour Time Format: All time representations now consistently use a 24-hour format, removing ambiguity from AM/PM.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request updates date formatting to use the IST timezone and a 24-hour format. The changes are applied consistently across several frontend and backend files. However, this introduces significant code duplication for the date formatting options and an inconsistency in the locale used (en-US vs. en-IN). My feedback focuses on refactoring this duplicated logic into a shared utility or constant to improve maintainability and ensure a consistent date format across the application.

// Create form data matching the curl command format
const formData: Record<string, any> = {
name: `${currentTemplate?.name || "Workflow"} - ${new Date().toLocaleString()}`,
name: `${currentTemplate?.name || "Workflow"} - ${new Date().toLocaleString("en-US", { timeZone: "Asia/Kolkata", hour12: false, year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit' })}`,
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

To improve maintainability and ensure consistency, consider creating a shared utility for date formatting. The current implementation hardcodes the formatting options, which are duplicated in several other files. A shared utility would centralize this logic.

Additionally, this file uses the en-US locale, while others use en-IN. Standardizing on a single locale (e.g., en-IN for the 'Asia/Kolkata' timezone) would prevent inconsistencies in date representation (DD/MM/YYYY vs. MM/DD/YYYY).

Comment on lines +13 to +22
return date.toLocaleString("en-US", {
timeZone: "Asia/Kolkata",
hour12: false,
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
second: '2-digit'
})
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

While combining toLocaleDateString and toLocaleTimeString is a good refactor, it introduces a new issue of duplicated date formatting options across the codebase. It's best to define these options in a shared constant or utility function to avoid inconsistencies and make future changes easier.

Also, please note the locale inconsistency: en-US is used here, whereas other parts of the app use en-IN for the same timezone.

// Create form data matching the curl command format
const formData: Record<string, any> = {
name: `${workflowName} - ${new Date().toLocaleString()}`,
name: `${workflowName} - ${new Date().toLocaleString("en-IN", { timeZone: "Asia/Kolkata", hour12: false, year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit' })}`,
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

The date formatting options are duplicated from other files. To promote code reuse and prevent inconsistencies, please extract this logic into a shared utility function or constant. This file correctly uses the en-IN locale, which seems more appropriate for the IST timezone, but this highlights an inconsistency with other files that use en-US.

</span>
<span className="text-xs text-gray-900">
{new Date(step.completedAt).toLocaleString()}
{new Date(step.completedAt).toLocaleString("en-US", { timeZone: "Asia/Kolkata", hour12: false, year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit' })}
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

The date formatting options are hardcoded here and duplicated across multiple files. This should be refactored into a shared utility to improve maintainability.

This change also introduces an inconsistency in locale usage (en-US here vs. en-IN elsewhere). A shared utility would help enforce a standard.

name:
requestData.name ||
`${template[0].name} - ${new Date().toLocaleDateString()}`,
`${template[0].name} - ${new Date().toLocaleString("en-IN", { timeZone: "Asia/Kolkata", hour12: false, year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit' })}`,
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

The date formatting options are hardcoded and duplicated in multiple places within this file (lines 743, 1916) and across the project. This is a maintenance concern. Please define these options in a single, shared constant or utility function.

For example:

const IST_DATE_FORMAT_OPTIONS: Intl.DateTimeFormatOptions = {
  timeZone: 'Asia/Kolkata',
  hour12: false,
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  second: '2-digit',
};

Using a shared constant will also help resolve the en-IN vs. en-US locale inconsistency between the frontend and backend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant