Support Linked Timezones

[adamsanderson]

I may be missing something, but is it possible to reference linked timezones? For instance, I have users with the US/Pacific timezone, which I believe is linked to America/Los_Angeles. If I try to operate on times with US/Pacific, timezone seems to silently assume UTC:

> now
1363302327446
> then = tz(now, 'America/Los_Angeles', '-14 days')
1362096327446
> then = tz(now, 'US/Pacific', '-14 days')
1362092727446

Any suggestions? Also, is there any way to find out if a timezone was not found, a strict mode perhaps?

[bigeasy]

A bug and a good suggestion. Will fix. Will consider. (Send from phone.)

On Thursday, March 14, 2013, Adam Sanderson wrote:

I may be missing something, but is it possible to reference linked
timezones? For instance, I have users with the US/Pacific timezone, which
I believe is linked to America/Los_Angeles. If I try to operate on times
with US/Pacific, timezone seems to silently assume UTC:

now
1363302327446
then = tz(now, 'America/Los_Angeles', '-14 days')
1362096327446
then = tz(now, 'US/Pacific', '-14 days')
1362092727446

Any suggestions? Also, is there any way to find out if a timezone was not
found, a strict mode perhaps?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/144
.

[bigeasy]

Are you blocking on a solution? I can do a release now with this temporary fix. I'll do a more thorough implementation of links over the weekend.

[adamsanderson]

Thanks for the quick turnaround! Don't worry about a release just for me,
if needed, I can pull your fix from github.

I think I actually need something more low level. I'm doing thousands of
day iterations, thousands of times in a simulation that needs to be DST
aware, ie: it needs accurate wallclock times. I think I might actually
just get a posix day start, then increment by a day of milliseconds, and
adjust whenever I trip over a rule's boundary. I may still use the JSON
datafiles you're producing.

By the way, I really liked your synopsis.js, that's an excellent overview
of the library.

On Fri, Mar 15, 2013 at 1:57 PM, Alan Gutierrez notifications@github.comwrote:

Are you blocking on a solution? I can do a release now with this temporary
fix. I'll do a more thorough implementation of links over the weekend.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/144#issuecomment-14984469
.

[bigeasy]

Thank you for the feedback on synopsis.js. I've not made it prominent because I keep meaning to do something more substantial for documentation, so I can see I'm missing an opportunity because of the something better I'll probably never get around to.

It sounds like you're invoking tz a bunch, so it might actually be performance critical. I've got a handful of branches where I've done optimizations, with some significant improvements. I've held back because I wanted to keep the library tiny (2.7k), but if someone has a need for the performance, it would be worth exploring.

What date string are you using to get local time? I can see if any of the optimizations are faster for that specific case.

[adamsanderson]

My use case would looks roughly like this:

var pacific = tz('America/Los_Angeles');
var timestamp = 1363302327446; // Some timestamp, I would probably have

some code to pin it to 00:00:00 for the date
var end = 3 * 365; // scan through 3 years

for (var i=0; i < end; i++) {
  process(timestamp)
  timestamp = pacific(timestamp, '+1 day');
}

In process I mucking around with getting hour offsets on timestamp (ie:
timestamp + hours * (60_60_1000) ) and such.

On Fri, Mar 15, 2013 at 4:12 PM, Alan Gutierrez notifications@github.comwrote:

Thank you for the feedback on synopsis.js. I've not made it prominent
because I keep meaning to do something more substantial for documentation,
so I can see I'm missing an opportunity because of the something better
I'll probably never get around to.

It sounds like you're invoking tz a bunch, so it might actually be
performance critical. I've got a handful of branches where I've done
optimizations, with some significant improvements. I've held back because I
wanted to keep the library tiny (2.7k), but if someone has a need for the
performance, it would be worth exploring.

What date string are you using to get local time? I can see if any of the
optimizations are faster for that specific case.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/144#issuecomment-14991364
.