We work a lot with timezones, but none of it is in the dial plan. There
are currently 383 time zone rules which are driven by the zoneinfo files
which are derived from the Olsen Database. If you are supporting users
from all over the world, it can get very complicated.
In North America there are a few weird places that you have to consider,
Saskatchewan, which doesn't observe daylight savings time, and there is
a town in Saskatchewan ( Lloydminster) which is actually on mountain
time and observes DST. If you have US needs then you have things like
Arizona not observing DST and other states which are in 2 timezones plus
Indiana which has 3 rules depending on which county you are in.
From years of experience we have distilled it down to using a database
and perl modules to accurately track local time. You make it easy for
maintaining by creating a table for timezone which has a field with it's
correct zoneinfo name, default UTC offset and current UTC offset (make
sure these are decimal fields not integers), then a city table which has
every city your are supporting, and have a foreign key on each record to
the timezone table.
The perl DateTime modules ( DateTime::TimeZone ) are not the quickest in
the world so do not use them on the fly in your dial plan, instead what
we do is have a cron job that runs every 15 minutes to update the
timezone table and if it's current time offset has changed, update it.
Then use a db lookup to retrieve the current time for the user. If you
are only supporting North American you won't need to run it every 15
minutes but if you are supporting the world you do, since there are some
crazy rules and some timezones are off from ours by both 30 and 15
minutes. Also they do not all change their DST on a Sat night, some are
Friday, Sunday or even weekdays ( based on a national holiday, etc.... )
which moves every year.
Here are a few links to look at for further information.
http://en.wikipedia.org/wiki/Tz_database
http://tycho.usno.navy.mil/
Hope this helps!
Mike
On 05/30/2010 1:13 AM, Jim Van Meggelen wrote:
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]
--
Mike Ashton
Quality Track International
Work: +1 647 724 3500 x251
Cell: +1 416 527 4995
QTI CONFIDENTIAL AND PROPRIETARY INFORMATION
The contents of this material are confidential and proprietary to Quality Track
International, Inc.
and may not be reproduced, disclosed, distributed or used without the express
permission of an authorized representative of QTI.
Use for any purpose or in any manner other than that expressly authorized is
prohibited.
If you have received this communication in error, please immediately delete it
and all copies, and promptly notify the sender.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
