Overview
I propose we standardise the Date Time format used in API communication to the ISO 8601 format.
All Date Time parameters must be converted to UTC and follow the YYYY-MM-DDTHH:mm:ss.sssZ format (e.g., 2024-03-10T21:00:00.000Z) for both sending to and receiving from the API.
Proposed Structure
Date Time Format: All API routes(those that relate to date time ) expect Date Time parameters in UTC, specifically in the ISO 8601 format.
Underlying Implementation: The API utilizes TypeORM for CRUD operations, which converts string DateTime parameters into JavaScript Date objects for timestamptz column operations.
Frontend and Backend Communication: Both frontend and backend, developed in JavaScript, will adhere to this standardized Date Time format for ease of data manipulation and communication.
Database Interaction: When interacting directly with the PostgreSQL database, especially for raw queries, the extended ISO 8601 SQL standard format (YYYY-MM-DD HH:mm:ss.sss ±[hh]) should be used, acknowledging PostgreSQL's format requirements for timestamptz columns.
Rationale
The decision to use the mentioned ISO 8601 format over the SQL date time standard is influenced by:
Global Standardization: ISO 8601 is a globally recognized standard, facilitating easier integration and consistent formatting across different systems and technologies.
Ecosystem Cohesion: The exclusive use of JavaScript across our stack simplifies DateTime handling and conversion, reducing the risk of format-related errors.
Compatibility with TypeORM: TypeORM's reliance on JavaScript Date objects makes ISO 8601 the more compatible choice for our operations.
UTC settings: ISO 8601 format will ensure consistency with our reliance on UTC settings for date time operations as outlined in issue #20.
Expected Benefits
Consistency: A unified Date Time format across the API ensures consistent data handling and interpretation.
Simplicity: Simplifies the conversion and comparison of Date Time values across different time zones.
Interoperability: Enhances the API's compatibility with external systems and services by adhering to a widely accepted standard.
Efficiency: Streamlines backend and frontend communication, reducing the need for repetitive format conversion.
Request for Comments
I invite all team members to review this proposal and provide feedback or concerns regarding this adoption for our API communications. Your insights are invaluable in ensuring that we choose the most effective and efficient approach to Date Time handling in our system.
Overview I propose we standardise the Date Time format used in API communication to the ISO 8601 format. All Date Time parameters must be converted to UTC and follow the
YYYY-MM-DDTHH:mm:ss.sssZformat (e.g.,2024-03-10T21:00:00.000Z) for both sending to and receiving from the API.Proposed Structure
timestamptzcolumn operations.YYYY-MM-DD HH:mm:ss.sss ±[hh]) should be used, acknowledging PostgreSQL's format requirements fortimestamptzcolumns.Rationale The decision to use the mentioned ISO 8601 format over the SQL date time standard is influenced by:
Expected Benefits
Request for Comments I invite all team members to review this proposal and provide feedback or concerns regarding this adoption for our API communications. Your insights are invaluable in ensuring that we choose the most effective and efficient approach to Date Time handling in our system.