[Gambas-user] possible bug in gb. loggig
adamnt42 at gmail.com
Tue Sep 15 05:58:36 CEST 2020
Looks like this never got delivered.
On 14/9/20 11:26 pm, Bruce wrote:
> Inline, and from dim memory of when I was involved in writing the
> original Logger.
> On 14/9/20 5:21 pm, Angel wrote:
>> It seems that the Formatter () function calls GetCallLocation ()
>> Private Function GetCallLocation () As String
>> Dim iCount As Integer = 1
>> While System.Backtrace [iCount] Begins "Logger" Or System.Backtrace
>> [iCount] Begins "Formatter"
>> Inc iCount
>> Return System.Backtrace [iCount]
>> When the Formatter () function is called from the ComplexLogger class,
>> when the GetCallLocation () function is reached
>> at some point System.Backtrace [iCount] has a value of
>> "ComplexLogger.Log.60" and exits before reaching the function used by
>> the ComplexLogger class.
> It looks like the Formater also needs to detect ComplexLogger as well as
> the other two unwraps. i.e.
> While System.Backtrace [iCount] Begins "Logger" Or
> "Formatter" Or System.Backtrace[iCount] Begins "ComplexLogger"
> ( The comlexLogger was addad after I last has access to the source.)
>> I would also like (if possible) the author to change the calls in
>> Formatter () from Cstr () to Str () since curious errors can occur if
>> the format is $ (date) depending on the location.
> From very dim meory there was a reason for doing that at the time.
> Perhaps it had to do with logging across time zones onto a server
> running the application using the logger. Actually IIRC it was in our
> Auction system that used a client program in one timezone (actually
> several clients in different timezones) and logged events all had to be
> co-ordinated into a single reference "field" so we used a UTC stamp.
> Maybe not, it was simply that long ago.
> But anyway and if the code is wrong with the newer date handling regime
> then consider the issue of logging across timezones anyway. Somehow the
> logging time must be co-ordinated to a single frame of reference.
> If a program running in UTC+10 writes a message to a centralised log
> file somewhere and this is followed by another system running in UTC+6
> and they bith write messages in their local time then the log will be
> "out if order". To surmount that I think we decided to only write times
> in UTC. That way the messages should appear "in order" regardless of the
> time on the system that logs the message.
> Of course that means the anything (people included) trying to interpret
> the log have to be aware of what the timestamp really means. If you
> think about it this way even if you are composing in a single time
> frame, the log file still must register timestamps within a single
> defined frame. What would happen at daylight savings changeover.....
More information about the User