You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fixing minute offset issue in certain time zones (#1238)
Timezones with minute offsets not divisible by 60 were causing issues for converting from the driver implementation of Date and Datetime to JS Date. A better implementation has been created and some documentation has been updated to reflect limitations that already existed.
* Create a {@link Date} object from the given standard JavaScript `Date`.
355
355
* Hour, minute, second, millisecond and time zone offset components of the given date are ignored.
356
+
*
357
+
* NOTE: the function {@link toStandardDate} and {@link fromStandardDate} are not inverses of one another. {@link fromStandardDate} takes the Day, Month and Year in local time from the supplies JavaScript Date object, while {@link toStandardDate} creates a new JavaScript Date object at midnight UTC. This incongruity will be rectified in 6.0
358
+
* If your timezone has a negative offset from UTC, creating a JavaScript Date at midnight UTC and converting it with {@link fromStandardDate} will result in a Date for the day before.
359
+
*
356
360
* @param {global.Date} standardDate - The standard JavaScript date to convert.
* The time component of the returned `Date` is set to midnight
373
377
* and the time zone is set to UTC.
374
378
*
379
+
* NOTE: the function {@link toStandardDate} and {@link fromStandardDate} are not inverses of one another. {@link fromStandardDate} takes the Day, Month and Year in local time from the supplies JavaScript Date object, while {@link toStandardDate} creates a new JavaScript Date object at midnight UTC. This incongruity will be rectified in 6.0
380
+
*
375
381
* @returns {StandardDate} Standard JavaScript `Date` at `00:00:00.000` UTC.
expect(standardDate.getUTCDate()).toEqual(datetime.day)// The datetime in this test will never cross the date line in conversion, it is therefore safe to use UTC here to avoid machine timezone from altering the result of the test.
0 commit comments