I use this in other applications also since we have clients around the
world so we need a common module/method for all applications. We run all
our servers set to UTC that way you don't run into any confusion.
Database events have server timestamp UTC and the clients local
timestamp, that way we do not have to do any calculations after the fact
to properly represent it since current UTC offset may not be the same as
it was when the event happened if you have the need for historical
reporting in the users local timezone.
I'll have to look into this feature in 1.6.2
Mike
On 05/30/2010 12:45 PM, Jim Van Meggelen wrote:
Mike,
Thanks a ton for that information.
Thing is, with Asterisk 1.6.2 they are now including the timezone
argument in all the time-related functions and parameters. As near as
I can figure, what this means is that as long as time timezone is
recognized by Linux, using that argument should allow asterisk to
calculate the difference between the system time and the time being
referred to in the application (which is really all any timezone
calculation comes down to). This should greatly simplify working with
timezones in the dialplan (or so I hope).
So it's still important to know exactly what timezone you're dealing
with (for example, I have a customer in Houston, and had to ask them
what timezone value they used on Linux servers--turns out it's
Chicago), but once you know the timezone, as long as it's in Linux,
one would expect this should work fairly simply and reliably.
We'll see :-)
Jim
On 5/30/2010 11:37 AM, Mike Ashton wrote:
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]> <mailto:[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] <mailto:[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]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[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]
--
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]
