It looks as if asterisk 1.6.2 may have what I'm looking for:
http://linuxinnovations.com/core1.4-1.6.2.html
(search for timezone)
On 5/30/2010 12:59 AM, Jim Van Meggelen wrote:
The voicemail thing works well, but it doesn't handle things like
business hours and remote calling settings (e.g. don't call me after
5PM on Fridays, or whatever).
I'm sure some sort of shell or perl script can be whipped off to
handle this sort of thing, but ideally I'd want something that could
be done in dialplan as much as possible (or a one line system call, I
guess).
So many tools in Linux. Hard to make sense of them all.
On 5/30/2010 12:53 AM, Dave Donovan wrote:
Jim,
Your message prompted me to think that if I hang my San Diego users of
my Mississauga PBX, the voicemail timestamps would be wrong. It looks
like someone thought of this already. It doesn't handle your
calculation issue, but if you're going to set it up once in the
voicemail, you might wish to leverage that in your dialplan as well.
Maybe something along the lines of a GetUserTime(user, ArbitraryTime)
function would be handy.
From: http://www.voip-info.org/wiki/view/Asterisk+config+voicemail.conf
Settings for the [zonemessages] section of voicemail.conf
The zonemessages section allows the adminstrator to define custom time
zones, and to change the way time is announced in a particular time
zone. Users may have different time zone settings, and also different
formats for announcing the date and time of voicemail messages. When a
time zone is defined here, you may use it in individual malboxes by
specifying a tz= option on the individual mailbox entry (Mailbox
entries are discussed in the next section on contexts). The format of
a zonemessages entry is:
newzonename=Country/City|Options
Sorry I don't have _the_ answer to your inquiry but I'll be looking
into this and I'll let you know if I find something useful. Please
keep us posted on what you learn as well. We can't be the first to
have this issue so there must be some good solutions out there.
Dave
On Sat, May 29, 2010 at 11:44 PM, Jim Van
Meggelen<[email protected]> wrote:
All sorts of things in the dialplan might be dependant on the timezone.
If users and companies are in a timezone that is different from the
zone of the server, how can one manage that?
I thought about just calculating the difference between the system
time and the user's time zone, but this can get tricky.
For example, in Saskatchewan they don't use daylight saving time (at
least not last time I checked). This means that for half the year,
they are on Central Standard Time, and half the year they are
effectively in Mountain Daylight Time.
So a dialplan that's on a server in Eastern Time, which needs to
calculate when to do certain things for users in Saskatchewan, would
need to know when they are 1 hour different, and when they are 2
hours different.
The data is all in Linux (the zonedata files are extensive), however
I can't figure out an easy way to have the timezone calculations
handled. My thinking was to assign a user to a zonedata file, and
then run a function against that to calculate the difference between
their zone, and the zone of the server.
Anybody done anything like this?
Any experiences or suggestions would be most appreciated.
Regards,
Jim
--
--
Jim Van Meggelen
[email protected]
http://www.oreillynet.com/pub/au/2177
"A child is the ultimate startup, and I have three.
This makes me rich."
Guy Kawasaki
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
--
Jim Van Meggelen
[email protected]
http://www.oreillynet.com/pub/au/2177
"A child is the ultimate startup, and I have three.
This makes me rich."
Guy Kawasaki
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
