keystonejs/keystone-classic

Datetime field type adds 5 hours to data

Open

#4082 opened on Mar 9, 2017

View on GitHub
 (9 comments) (0 reactions) (0 assignees)JavaScript (14,656 stars) (2,288 forks)batch import
help wantedneeds confirmation

Description

Expected behavior

When converting a JavaScript Datetime object to an ISOString and then uploading to a KeystoneJS app, I expect the get the same time string back from the server.

Actual behavior

The Datetime string returned by the server has 5 hours appended to the value.

Steps to reproduce the behavior

  1. I create a model with a Datetime field like so: reportGenerated: { type: Types.Datetime, default: Date.now }

  2. Below is an example of an object with JavaScript Date objects:

Image 1

  1. I use an API, similar to the API Gist by Jed or the File and Image API Guide. That API will reject JavaScript Date objects, but will accept an ISO string. Here is an example of the same object with it's Date objects converted to ISO strings using Date.toISOString() in preparation of uploading to the KeystoneJS server:

Image 2

  1. Send data to the server succeeds. However, when retrieving the same data from the server, the ISO strings have 5 hours added to them:

Image 3

Contributor guide

Tech stack
javascriptnodejsmongodb
Domain
backenddatabase
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
Basic JavaScriptNode.js/KeystoneJSTime zone concepts
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
60
Research direction
Investigate the Datetime field type in KeystoneJS, likely in `keystone/fields/types/datetime.js`. The bug suggests a timezone offset of +5 hours is being added during serialization/deserialization. Check how the field stores dates (likely as ISO strings) and whether it incorrectly applies a UTC offset. Look at the `format` and `parse` methods, and compare with the behavior described in the issue. No linked PRs or comments indicating a fix, so this is an open opportunity.