Should all times be in microseconds?

[Robert Jacobson]

In the continuing saga of my 'inherited' Trac server...

Some of the reports are using 'time' or 'changetime', inside a datetime function, like:

datetime(time,'unixepoch') as 'Date Created'

Unfortunately, it appears that the times in the database are microseconds since unixepoch, so I get some very odd results.

The most-obvious fix is to change the report(s) to use:

datetime(time/1000000,'unixepoch') as 'Date Created'

However, I'm wondering if I really should be doing that.  First, there are dozens of reports like this.  Obviously at one time, the time was stored in seconds.

Did something change between Trac 0.12 and 1.2.3 so that times in the database were changed to microseconds instead of seconds?  (e.g. something in the 'upgrade' process?  Or is something else going on?  If times changed due to 'upgrade' -- shouldn't 'upgrade' also modify the reports or at least provide a warning? :)

[Jun Omae]

On Wed, May 15, 2019 at 8:04 PM Robert Jacobson <ter...@gmail.com> wrote:
> However, I'm wondering if I really should be doing that. First, there are dozens of reports like this. Obviously at one time, the time was stored in seconds.
>
> Did something change between Trac 0.12 and 1.2.3 so that times in the database were changed to microseconds instead of seconds? (e.g. something in the 'upgrade' process? Or is something else going on? If times changed due to 'upgrade' -- shouldn't 'upgrade' also modify the reports or at least provide a warning? :)

You can check release notes [1] and API changes [2] any time.

Timestamp storage have been changed from seconds to microseconds
between Trac 0.11.x and 0.12. No changes of timestamp storage between
Trac 0.12.x and 1.2.x (including trunk).

[1] https://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.12#Reports
[2] https://trac.edgewall.org/wiki/TracDev/ApiChanges/0.12#Timestampstorageindatabase

--
Jun Omae <jun...@gmail.com> (大前 潤)