Elapsed time starts at one hour at the beginning of the meeting

Hello Jitsiers !

This is my first time here, I hope this question is relevant to the Install & Config category. If I’m mistaken please tell me and I’ll move it towards the correct category.

So, I just installed my first Jitsi instance (well, actually my third, I completely messed up the domains and host names the first times) following the quick-install guide on the GitHub repo. I eventually works fine on jitsi.gaael.dev, yay !

I only have one problem : when opening a new room, the elapsed time starts at 1 hour. It is not a really big deal, but I have no idea where this might come from. Example here.
It happens with Firefox and Chromium on my computer, with Firefox and Chrome on a friends’ computer (on a different IAP), with Firefox and the Jitsi app on my phone (on 3g network). It does not happen on the official jitsi instance. So I guess the problem comes from my server configuration.

Since I’m at a loss here I don’t know which information would be relevant. I’ll be happy to provide what happens to be useful.
Server config : VPS (at OVH) with Debian 10 (freshly installed and up-to-date), almost no package except for gnupg2 and ufw installed before running the jitsi install procedure.

So, any idea of where to start digging would be great !

Which prosody are you using?

You better update to 0.11 (don’t forget setting storage after upgrading it)

Result of $ apt policy prosody :

  Installed: 0.11.2-1
  Candidate: 0.11.2-1
  Version table:
     0.11.4-1~bpo10+1 100
        100 http://deb.debian.org/debian buster-backports/main amd64 Packages
 *** 0.11.2-1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

So I’d say 0.11.2-1.

I used jitsi-meet quick install process, which was mostly automatized, so I did not set storage during prosody install process.

About storage in /etc/prosody/prosody.cfg.lua :

-- Select the storage backend to use. By default Prosody uses flat files
-- in its configured data directory, but it also supports more backends
-- through modules. An "sql" backend is included by default, but requires
-- additional dependencies. See https://prosody.im/doc/storage for more info.

--storage = "sql" -- Default is "internal" (Debian: "sql" requires one of the
-- lua-dbi-sqlite3, lua-dbi-mysql or lua-dbi-postgresql packages to work)

About storage in /etc/prosody/conf.avail/jitsi.gaael.dev.cfg.lua :

Component "conference.jitsi.gaael.dev" "muc"
    storage = "memory"
    modules_enabled = {
        -- "token_verification";
    admins = { "focus@auth.jitsi.gaael.dev" }

-- internal muc component
Component "internal.auth.jitsi.gaael.dev" "muc"
    storage = "memory"
    modules_enabled = {
    admins = { "focus@auth.jitsi.gaael.dev", "jvb@auth.jitsi.gaael.dev" }

Should I change something here ?

If I understand correctly, default storage is internal but for the jitsi Vhost, conference and authentication components are stored to memory (and erased as soon as the conference ends then ?)

I have the exact same issue on a clean install (even clean OS) where I first installed prosody (to force install with version 0.11+) and then I installed jitsi-meet.
The timer starts at 59:55 and then counts towards the 1:00:00.

  Installed: 0.11.5-1~bionic6

Hello Everyone,
I confirm - the same problem happens on a fresh jitsi-meet installation on the latest Debian 10 VPS. Conference time starts at 1 hour (1:00:00). Prosody version is 0.11-2

Can you open an issue on github in jitsi-meet project, thanks.

Done. Thanks a lot @damencho for all the work.

I did some research and managed to fix the problem myself. The problem appears to be with line 31 of the /usr/share/jitsi-meet/prosody-plugins/mod_conference_duration_component.lua file (at least that’s where it’s located on Debian by default).
The suspect line is here:
room.created_timestamp = os.time(os.date("!*t")) * 1000; – Lua provides UTC time in seconds, so convert to milliseconds

To fix the conference elapsed time i modified the equation like this:
room.created_timestamp = os.time(os.date("!*t")) * 1000 + 3600000; – Lua provides UTC time in seconds, so convert to milliseconds

so i basically added one hour to it, rebooted my box and it did the trick. Now the meeting time starts exactly at 00:00:00 and counts upward like it’s supposed to.

I’m no software developer, however i think the cause of the problem is that this lua script fetches the raw UTC time and my server is in UTC+1 timezone so I get why the time was 1 hour out. So it doesn’t compensate for the timezone the server is set to.

Hope this helps to narrow down the search and develop some permanent solution to this issue.


Will try this later today on my instance, thanks :slight_smile:

Tried it on my instance, workaround works great.
So if I understand correctly, prosody creates a timestamp for the beginning of the meeting based on the server clock, and the meeting timer shows the difference between this timestamp and the users’ computer’s clock, is that right ?

Glad it worked for you :smiley:

So yeah, that’s right. I tested in on my server by setting the timezone to Moscow (UTC+3), rebooted the server and created a meeting - as expected time jumped 2 hours ahead, hence conference time started at 2:00:00 instead of 0:00:00
Like I said, there is no compensation for the server timezone in this case. The user’s timezone setting is irrelevant in this case.


as a workaround you can also change the

room.created_timestamp = os.time(os.date("!*t")) * 1000;


room.created_timestamp = os.time(os.date("*t")) * 1000;

The filename is /usr/share/jitsi-meet/prosody-plugins/mod_conference_duration_component.lua
I removed the exclamation mark in front of the *t. According to the lua docs this makes the difference between UTC and the Servertimezone.

Only a dirty fix but works for now…


Hi there. Had the same problem and solved it by just hiding the timer. True reason is that my app needed a countdown anyway, and from the time all participants had joined. So I made it on my side and added a countdown overlay on my window (I use the external api, and my web server is counting time, not my jitsi one).

That being said, @mamu solution is better IMHO :

as a workaround you can also change the

room.created_timestamp = os.time(os.date("!*t")) * 1000;


room.created_timestamp = os.time(os.date("*t")) * 1000;

because in this case you force time to UTC. And the great thing about it is that UTC is ALWAYS UTC. In other solutions, you’ll have to edit the file twice a year, because timezones (let say Europe/Paris) will vary between UTC+1 and UTC+2 depending on summer time / winter time. Same for all timezones AFAIK. And you mostly set your server time with a timezone, not a plain UTC+1.

And the biggest thanks to Jitsi team. Guys that’s a GREAT job !

Ok, so I’d say that the real issue here is not the timezones but the fact that Jitsi compares the server timestamp with the client current time to compute the meeting duration.

Do you think the expected behaviour would be to :

  • run all the calculations on the server and send the results to the client ?
  • run all the calculations in the client’s browser ?
  • find a way to automatically manage the timezone differences and keep the current system of server timestamp + client calculations ?

I’ll update and narrow the GH issue after getting your opinion on this, @Martini @mamu and @jusquiame.

As far as i understood the Problem the Server takes the UTC Timestamp, the Client its local timezone timestamp and those to values are compared.

The Server is already doing the right thing, the client has to take the correct timestamp as well (UTC).

Actual link to the issue (the link of my reply pointed to the general list of issues on GH) : Meeting clock starting at one hour #5595
Thanks @gpatel-fr for notifying me !

1 Like

Hi @jusquiame I am using external api same prosody. I can not see timer on my conference room. I think I am missing some configuration. Can you tell me how to show the timer on the conference room. Thanks

If you are using secure domain make sure timer is enabled on the guest virtualhost.