I found that all 'creation' field of new node is set to time when
roundup-tracker server was started.

This is because things changed in date.py:
from
   def __init__(self, spec='.', offset=0, add_granularity=False,
to
   def __init__(self, spec=datetime.datetime.utcnow(),

Revert it back solve the problem.

Good Morning,
Do you mean line 305 of ./roundup/date.py in the roundup core ?
In my mercurial copy which I got from sourceforge there is still 
the period (which looks correct to me).

Best regards, Peter Funk

Yes, i mean line 305.

I'm not sure but may be it introduced by changeset 4994:fe140bc0eaa9

Anthony added the comment:
> Yes, i mean line 305.
> 
> I'm not sure but may be it introduced by changeset 4994:fe140bc0eaa9

Not in my mercurial working copy.
I cloned it from sourceforge last week. Here I've this::

   Mercurial
   changeset 4986:fe140bc0eaa9

   Implement (and document) timezone offsets
   author 	Ralf Schlatterbeck <rsc@runtux.com>
   date 	Tue, 21 Apr 2015 17:33:06 +0200 (10 months ago)
   parents 	07c59221f363
   children 	f47341cbe3c8
   files 	roundup/date.py

and the line 305 in that file was not touched by this changeset. 

pf@pfmaster-P170EM:pts/28 ~/roundup 93> sha256sum roundup/date.py
b1b72ec5ceff6077dde0ce94b34c7c2009f5d564b6a75a0f7339308d098dba62 
roundup/date.py

This should be the head (tip) of the official Roundup source, or not?

Best regards, Peter

My recent changeset of date.py is       5002:03505579abef

I don't want t to mislead because my roundup-tracker source contain my
patches. But i've never touch this line.

I found this after pull and merging with roundup source tip 5055:dce3cfe7ec61

> Peter Funk added the comment:

> Anthony added the comment:
>> Yes, i mean line 305.
>> 
>> I'm not sure but may be it introduced by changeset 4994:fe140bc0eaa9

> Not in my mercurial working copy.
> I cloned it from sourceforge last week. Here I've this::

>    Mercurial
>    changeset 4986:fe140bc0eaa9

>    Implement (and document) timezone offsets
>    author       Ralf Schlatterbeck <rsc@runtux.com>
>    date         Tue, 21 Apr 2015 17:33:06 +0200 (10 months ago)
>    parents      07c59221f363
>    children     f47341cbe3c8
>    files        roundup/date.py

> and the line 305 in that file was not touched by this changeset. 

> pf@pfmaster-P170EM:pts/28 ~/roundup 93> sha256sum roundup/date.py
> b1b72ec5ceff6077dde0ce94b34c7c2009f5d564b6a75a0f7339308d098dba62 
> roundup/date.py

> This should be the head (tip) of the official Roundup source, or not?

> Best regards, Peter

> ________________________________________________
> Roundup tracker <issues@roundup-tracker.org>
> <http://issues.roundup-tracker.org/issue2550904>
> ________________________________________________

Anthony, may be we discovered a malfunction in Mercurial here?

I'm not so experienced with Mercurial until now.  To make
sure that I did not made a silly mistake I now did a fresh clone as
described here: http://www.roundup-tracker.org/code.html with the
command::

   hg clone http://hg.code.sf.net/p/roundup/code roundup-20160303-fresh
   
This file ``roundup/date.py`` looks okay to me:

pf@pfmaster-P170EM:pts/27 ~/roundup-20160303-fresh 51> hg log
roundup/date.py | head
Änderung:        4991:03505579abef
Nutzer:          Ralf Schlatterbeck <rsc@runtux.com>
Datum:           Sun Jun 21 20:55:21 2015 +0200
Zusammenfassung: Fix bug in (Date- or Interval-) Range parsing

Änderung:        4986:fe140bc0eaa9
Nutzer:          Ralf Schlatterbeck <rsc@runtux.com>
Datum:           Tue Apr 21 17:33:06 2015 +0200
Zusammenfassung: Implement (and document) timezone offsets

pf@pfmaster-P170EM:pts/27 ~/roundup-20160303-fresh 52> pr -t -n 
roundup/date.py | head -310 | tail
  301
  302           >>> test_fin(u)
  303       '''
  304
  305       def __init__(self, spec='.', offset=0, add_granularity=False,
  306               translator=i18n):
  307           """Construct a date given a specification and a time
zone offset.
  308
  309           'spec'
  310              is a full date or a partial form, with an optional
added or

Ok, Peter.
I'm also not an experienced Mercurial user. May be i confuse myself by
wrong VCS applying.
I think If nobody else found this line issue may be closed.

Thank you for your response.