I'm sure it won't be a panacea, but it'll sure help.
Heck, we used to have trouble setting up meetings, since everyone would
assume their own timezone. Got used to it; now everybody always says a
timezone along with the proposed time.
For logging, yeah, it'll require understanding what zone was used for
the timestamp, and how that relates to the timezone of the user.
One thing at a time ;-)
Jim
On 5/30/2010 1:24 PM, Mike Ashton wrote:
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]>
<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]>
<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]>
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]> <mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[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]
<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]
--
--
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
--
