newDateInternal does not adjust creation from fixed point date strings

[jason-codaio]

trafficstars

Modifying the in documentation editor to:

Sugar.Date.setOption('newDateInternal', function() {
  var d = new Date(), offset;
  offset = (d.getTimezoneOffset() - 600) * 60 * 1000;
  d.setTime(d.getTime() + offset);
  return d;
});
Sugar.Date.create("1/20/2017 7:15 pm").toString();

Returns "Fri Jan 20 2017 19:15:00 GMT-0800 (PST)" with the above code and if you overload offset to 0. I would expect the date string to be parsed with respect to Hawaii time, ie 5:15pm PST

[andrewplummer]

As the docs mention, newDateInternal is providing access to Sugar's internal date constructor (by default is simply new Date, this overrides it). When you use create to parse a string format, a new date is created, but it's properties are immediately overwritten by the parsed input, so it's effectively not doing anything.

[jason-codaio]

The documentation under timezones makes this a bit ambiguous as it implies you can some how use newDateInternal to integrate with timezone support.

However, special options are included that allows Sugar to play nicely with other libraries designed for this purpose. Specifically, the newDateInternal option allows dates created internally by Sugar to be transformed to simulate being in a different timezone.

I don't really see how that is possible. Sugar has great parsing, but I don't see how to easily connect it to timezone support especially without exposing the date parsing parts result.

[andrewplummer]

You're right about the docs, and admittedly this feature is nearly "hidden" in nature, and could be better thought out. It essentially began existence to allow Sugar to play nicely with timezone-js, which has pseudo date objects that conform to the native API. Sugar does not perform any type-checking on dates, so it will allow timezone-js dates to be used, but the problem became that a date would be manipulated from point of creation to the time it was returned, and there was no way to set the timezone in between, so this became the solution. For more context on this, see #342 as well as lib/extras/timezonejs-shim.js.

So now I throw the question back to you? Are you actually trying to do something with timezones? More to the point (as it's a question I've been pondering of late), would Sugar handling timezones be something you're interested in?

[jason-codaio]

Yes timezone support is important for me. We have multiple people around the world interacting with date based data and in our app we want all the data fixed to the same timezone instead of whatever happens to be that persons current local timezone. We used to use moment for this support, and I had to work around Sugar's lack of support by doing the date parse and then reading the parts back out using local interpretation and then using another library to take the [year, month, date, hour, minute, second] parts array to interpret it as the correct timezone.

Note this is still a bit tricky to use because the information about specificity is not exposed by the library. So when you receive back a date object you don't know if the original date string contained only time, an ambiguous date time with no timezone, or a full specified date string.