[Freeipa-devel] timestamps

[Dmitri Pal]

Simo Sorce wrote:
> 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.
>
>
>   
Makes sense but rises another interesting issue with the whole log
collection and aggregation logic.
Besides the event we also collect log files. It might be that the
application creates its log file in local locale (including time stamp).
How we would be able to index and co-relate log files potentially
written in different languages or with elements that are language specific.
I think the only good answer to that is to tell IT admins to configure
the logging applications to use a specific locale while logging.
So this means that ELAPI configuration (if the log file is created using
it) should support an override locale that will be used for things like
timestamps.
Such approach would allow to configure systems to emit consistently
readable logs. If admins what to see all the local dates in Chinese then
they would be able to configure that.

So to summarize this  part:

a) I still see a value in local time stamp but there should be a way to
configure specific locale
b) This local time stamp presence should be configurable


> 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.
>
>   
The problem will occur for the time zones that change its offset due to
some political decisions (which happens all the time -more than once per
year).
The tools that will be used in future (on the server) will not have
enough information (from the event) to calculate local time at the
moment of the event creation using just offset.
To do the right conversion they need to have the right time zone info so
that they can lookup the history and do the proper conversion.
With just offset the error will be the difference between the time zone
offset at the moment of the event creation and current timezone offset.
If the time stamp is written once at the creation (in the locale the
admin chooses) we avoid these problems altogether.


> Simo.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/