WallTimeDate Helper

[mattjohnsonpint]

I can convert a Date to a WallTime:

var wt = WallTime.UTCToWallTime(dt, "America/New_York")

I can convert a WallTime to a Date:

var dt = WallTime.WallTimeToUTC('America/New_York', 2013, 10, 7, 0, 0, 0, 0)

But how can I just represent a simple wall time? I would expect something like:

var wt = new WallTime('America/New_York', 2013, 10, 7, 0, 0, 0, 0);

(perhaps with an optional offset for resolving ambiguous wall times)

I want to be able to then take that wall time, get the offset in effect, display it with the correct name or abbreviation, etc.

[jgable]

The idea is that you shouldn't be creating straight wall times for yourself, otherwise what is the point of all the logic to get the time correct based on the rules?

As for representing a simple wall time, it's really just a matter of composing the two methods you mention. We haven't made a helper for it explicitly on the WallTime api, but here is what a method like that would have in it.

function WallTimeDate(zone, y, m, d, h, mi, s, ms) {
  var dt = WallTime.WallTimeToUTC(zone, y, m, d, h, mi, s, ms);
  return WallTime.UTCToWallTime(dt, zone);
}

// Usage
var wt = WallTimeDate('America/New_York', 2013, 10, 7, 0, 0, 0, 0);

wt.offset;
wt.save;

If you'd like to put together a PR with that helper in it, I'd consider adding it to the API.

[mattjohnsonpint]

Ok. Thanks. One more question:

Can I control how WallTimeToUTC resolves ambiguities? For example, if the wall time is during a fall-back DST transition, does it pick the first or second instance, and can I control that in any way?

[jgable]

Currently it behaves the same way that most browsers do, it will choose the time after the transition. So, if going forward from 2-3 and you say 2:30 it will actually be 3:30.

// http://www.timeanddate.com/worldclock/clockchange.html?n=64
var before = new Date(2013, 2, 10, 2, 30); // 1:30 AM -> 1:30 AM
var during = new Date(2013, 2, 10, 3, 30); // 2:30 AM -> 3:30 AM

Try that in your browser to confirm.

[mattjohnsonpint]

That's ok behavior for the missing time when transitioning from standard to daylight. But I'm more interested in behavior for the ambiguous duplicated time when transitioning from daylight to standard.

This is an issue in all date/time libraries that deal with DST (javascript or otherwise). Some pick the standard time. Some pick the "first" of the two times, which is usually the daylight time. Some give you control by letting you pass in the offset, and others return an error or throw an exception.

I've found that the behavior with JavaScript's Date object is different depending on the browser. I was hoping since walltime has it's own tzdb implementation that it would be more consistent.

BTW - this issue is the first of the two I bring up in my recent blog post. You should read. http://codeofmatt.com/2013/06/07/javascript-date-type-is-horribly-broken/

[jgable]

We resolve that case the same as the browser as well. There is no way to manipulate the way we disambiguate but you can check whether a date was ambiguous by WallTime.IsAmbiguous(zone, timestamp).

If you want to know which way it was ambiguous you can then check the save of the walltime for that timestamp to determine if it was a jump forward or back.

[getaaron]

@jgable Would it be okay if we closed this issue? I confirmed with @ravi77o and @david-huber that it's not under active development.

[ravi77o]

Hey @getaaron - I'll be in Chicago tomorrow and the following Monday and would love to discuss the fate of this issue. However, I saw on another social feed earlier that you will not be in Chicago on Friday. SAD.

[chrisege]

Ravi, come to the sprout office tomorrow and we'll get someone to provide an in-person review for any pull requests you want to submit to WallTime.

[chrisege]

@ravi77o @getaaron bump