World: r3wp

NTP not an option?

Sure, and Fossil will nicely warn me when it gets significant, and 
then I'll adjust it

NTP is on the roadmap for this server, but with low priority

Does Fossil issue a warning when you update?

yes

Strange, not for me, and the time of my workstation is routinely 
off

What system are you on?

Why would that matter?

Because I can't replicate it

My systems are properly time-synced.

Various Linuxes, fossil 047e06193b on all of them, all of them synced.

Mine aren't, so that must be the solution :-)

The esperconsultancy httpd is ~14 seconds off.

That's much better than I expected :-)

What's the date of your Fossil version?

This is fossil version [047e06193b] 2011-04-13 12:05:18 UTC.

I'm on the previous version of a month before, so maybe that makes 
a difference

Not really.

You're reporting a difference, aren't you?

2011-03-16 reports the same warning.

The difference is most likely that my systems have a synced time, 
whereas your workstation has not.

Yes, that's what I suggested

Exactly. The fossil version doesn't matter much.

So, I can't replicate your problem, and it doesn't prevent Fossil 
from functioning, does it?

You can easily replicate my problem: sync your system time properly.

Why would I?

It does not, but it'll give everyone with a synced time a warning 
on each and every clone/pull.

To replicate the problem. Of course, if you don't want to, that's 
fine.

That's good to know, thanks. But I have higher priority work

If a newer Fossil version would fix it, I would have been willing 
to update, though

Nothing to do with fossil.

The time on your server is off, simple as that.

It generates the warning, doesn't it?

03-16 generates the same warning.

If I make it better than 13 seconds, it will still be off

Okay, it is way off, then.

Fossil won't complain <10 secs.

OK, I'll keep that in mind when I look into NTP

But obviously, it's not something that keeps Fossil from working, 
it's just a friendly reminder that it tailors to the habits of the 
local user

Or actually more likely, it doesn't care about absolute time, but 
only about the relative time of the server and the local machine

Relative time between check-ins.

And it will try to prevent you from creating a check-ins that are 
"earlier" than their parents.

Yes, so it may become relevant on highly popular projects with frantic 
contributions all during the day

it didnt complain for me

Or for a single contributor trying to create two check-ins in quick 
succession.

Only if he would switch machines within then seconds

ten

Or whatever the relative unsyncedness between the two machines is.

why the hell is it an issue at all? i think because of the versioning 
model depends too much on the timestamps...

which is not the case with darcs.