[Freeipa-devel] timestamps

[Simo Sorce]

Dmitri Pal wrote:
> Why not just sent as a separate field the local
> time in the format related to locale defined on the machine?  
> Such approach has a lot of benefits:
> 
> a) You do not need platform dependent code to get time zone
> b) You do not need to deliver locale to the central server
> c) You do not need to spend cycles on the central server doing conversions
> d) You can use the local time as is in the local logs (as syslog does)

Uhmmm I think using *localized* local time has one crucial problem, you
don't have a way to present what was the local time in other locales.

Take an example of a server in China, this would be a local time
(if you can't read it it is because you don't have the right fonts, I
installed cjkunifonts-uming.noarch):

2009年 07月 01日 星期三 11:35:25 EDT

Now if I have admins on a 24x7 basis it means 2 shifts a day will be
base in countries were people most probably don't speak chinese.
I am not even able to tell reliably given a random locale if it is Jan
7th or Jul 1st.
(I know it is July first in this case, that's not the point :-)

You can certainly ignore the local time in the logs, but then you do not
have enough information to convert UTC to the local time in your
language (say spanish: "mié jul 15 11:42:05 EDT 2009", not the month is
not present in numbers even.)

So even if you store the local time you should still store the timezone
info.


John Dennis wrote:
> > Dmitri and I were discussing the storage of timestamps yesterday. My
> > understanding of best practice (after much investigation) is to store
> > timestamps in UTC paired with the current zoneinfo (important
> > clarification, *not* the local offset, rather the *zoneinfo* [1]).

Now on this argument that you must store the zoneinfo and *not* the
displacement.

I think in this case this rule is not relevant.

You want to know the zoneinfo when you have a random daytime and you
want to stick to it *within* the zoneinfo. Example: 12:00 in NYC
Without a date the zoneinfo is crucial to be able to determine what is
12:00 in NYC on any given day.

But in logs this is not important, we have the exact UTC date at the
time of the event and the displacement *at the time of the event*.
It doesn't matter if we check this log now or in 1000 years. The
displacement *at the time of the event* do not change no matter what
(unless you are into rewriting history :-).

---
Conclusion:

I think that UTC + displacement is perfectly fine and conveys all the
data you need without adding unnecessary localized output that is
relevant only to a fraction of the people that may be actually analyzing
logs.

You may *also* add the localized local time, but you must add the
current local offset as well (in numbers like: -400 or +530 not in
letters as in EDT) or the zoneinfo.
Given zoneinfo is too difficult to get reliably the numeric time
displacement is fine.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York