Astervis Docs

Timezone Configuration

Configure timezone settings for correct time display

Astervis uses three timezone layers. All must be configured correctly for accurate time display.

Timezone Layers

LayerVariablePurpose
DatabaseAlways UTC (automatic)
PBX SourceMYSQL_TIMEZONEYour Asterisk server timezone
DisplayTIMEZONE, NEXT_PUBLIC_TIMEZONEHow times are shown to users

How It Works

Asterisk (local time) → Sync → Database (UTC) → API → Dashboard (display timezone)
  1. Asterisk writes CDR with its local time (e.g., Europe/Moscow)
  2. Sync converts to UTC using MYSQL_TIMEZONE
  3. Database stores everything in UTC
  4. Dashboard displays in TIMEZONE

If MYSQL_TIMEZONE doesn't match your PBX server's actual timezone, all call times will be wrong.

Configuration

Edit /opt/astervis/.env:

# Your Asterisk/FreePBX server timezone
MYSQL_TIMEZONE=Europe/Moscow

# Display timezone (what users see)
TIMEZONE=Europe/Moscow
NEXT_PUBLIC_TIMEZONE=Europe/Moscow

Common Timezones

RegionTimezone
MoscowEurope/Moscow
TashkentAsia/Tashkent
AlmatyAsia/Almaty
KyivEurope/Kyiv
MinskEurope/Minsk
LondonEurope/London
New YorkAmerica/New_York
Los AngelesAmerica/Los_Angeles

Full list: Wikipedia Timezone List

Finding Your PBX Timezone

On FreePBX/Sangoma

timedatectl
# or
cat /etc/timezone

Check MySQL Timezone

mysql -u root -p -e "SELECT @@global.time_zone, @@session.time_zone;"

If MySQL shows SYSTEM, it uses the server's OS timezone.

Applying Changes

After changing timezone settings:

cd /opt/astervis
docker compose down && docker compose up -d

Existing data in the database is already in UTC. Timezone changes only affect how times are displayed, not stored data.

Troubleshooting

Calls Show Wrong Time

Symptom: Calls appear several hours off from actual time.

Cause: MYSQL_TIMEZONE doesn't match PBX timezone.

Fix:

  1. Check PBX timezone: timedatectl
  2. Update .env: MYSQL_TIMEZONE=Your/Timezone
  3. Restart services

Different Users See Different Times

Symptom: Some users see correct time, others don't.

Cause: Browser timezone differs from configured display timezone.

Note: Astervis uses server-configured timezone, not browser timezone. All users see the same time.

DST (Daylight Saving Time) Issues

Symptom: Times are off by 1 hour after DST change.

Cause: Timezone configured as fixed offset (e.g., +03:00) instead of named timezone.

Fix: Use named timezones (e.g., Europe/Moscow) which handle DST automatically:

# Wrong
TIMEZONE=+03:00

# Correct
TIMEZONE=Europe/Moscow

Historical Data Has Wrong Times

Symptom: Old calls show wrong times, new calls are correct.

Cause: MYSQL_TIMEZONE was wrong during initial sync.

Fix: You need to re-sync historical data:

# Reset sync and re-import
sudo astervis-installer sync --reset

This will re-import all CDR data. For large databases, use --start-date to limit scope.

Best Practices

  1. Use named timezones — not UTC offsets
  2. Keep all three settings consistentMYSQL_TIMEZONE, TIMEZONE, NEXT_PUBLIC_TIMEZONE
  3. Match PBX timezone exactly — critical for correct sync conversion
  4. Don't change timezone after initial setup — existing data won't be converted

On this page