andrewplummer / Sugar

A Javascript library for working with native objects.

Home Page:https://sugarjs.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Date.create is not ignoring timezone abbreviations

tfrojd opened this issue · comments

According to npm page Sugar should ignore timezone abbreviations. However that seems to not work for me.

Sugar does not deal with timezone abbreviations (i.e. "PST", etc). Timezone offsets will be correctly parsed if they are in ISO-8601 format (+09:00, +0900, or Z for UTC), however if an abbreviation exists it will be ignored. Sugar however plays nicely with other libraries that offer full timezone support such as timezone.js.

require("sugar").extend();
console.log("startdate " + Date.create("January 12, 2018 09:00:00 MET", { future: true })); // Does not ignore TZ abbreviation
console.log("startdate " + Date.create("January 12, 2018 09:00:00 CET", { future: true })); // MET and CET is the same TZ
console.log("startdate " + Date.create("January 12, 2018 09:00:00 UTC", { future: true })); // Ignores as expected
console.log("startdate " + Date.create("January 12, 2018 09:00:00", { future: true }));

Output from console is

startdate Invalid Date
startdate Invalid Date
startdate Fri Jan 12 2018 10:00:00 GMT+0100 (CET)
startdate Fri Jan 12 2018 09:00:00 GMT+0100 (CET)

Running node v9.3.0 and sugar 2.0.4

Hi... apologies for taking ages here...
So it seems that all of the formats you're passing here except the last one are falling back to native browser parsing, which does NOT ignore timezone abbreviations. In a sense that makes what I've said in the docs completely true and a complete lie at the same time.

The fallback is at the heart of the issue here and in addition to problems like this is environment dependent, which is why it will be removed in the next major version (#638). At that point Sugar will correctly parse timezones but throw them away and treat the dates as a local time. I'll leave this ticket open, however, as a reminder to handle the abbreviated formats as well, which I still need to do.

Also a reminder to self here that the parsed timezones should be passed into the populated params object so that they can be handed off to a library that does deal with them.