Hi,

I hope I'm not missing the blindingly obvious here, but I have an issue with time and date formats

Extract from my elog.cfg file:


Time format = %a %d %b %y
Date format = %d %b
Thread display = $Ticket: $System, $entry time. ($message id). $status
Preset text = [$date]
Prepend on reply = [$date] \n

I can point to places in the syntax doc where each of these lines are given.

As for the results, the thread display is (for example):

T00001: Computer, Wed 29 Aug 12. (1). Problem

However, what I get at the top of the text box in starting a new entry or replying to a previous one is

[Wed 29 Aug 12]

whereas I expected to get

[29 Aug]

Putting $date instead of $entry time in the Thread display line makes (the by now expected) no difference

I cannot see where I'm going wrong.  

TIA 

David.

OK, I see that $date can work in a different way; if the Thread display uses $date,
then the present timestamp is substituted into the thread display line, rather than the 
date that the entry is entered.  So, for example, in a whole list of entry and replies, the present
date shows on each entry of the thread.  However, the format is still that as defined by
'Time format' rather than 'Date format'.

If nothing else, I cannot really see the point of the 'Date format =' in the way that this all works.

> Hi,
> 
> I hope I'm not missing the blindingly obvious here, but I have an issue with time and date formats
> 
> Extract from my elog.cfg file:
> 
> 
> Time format = %a %d %b %y
> Date format = %d %b
> Thread display = $Ticket: $System, $entry time. ($message id). $status
> Preset text = [$date]
> Prepend on reply = [$date] \n
> 
> I can point to places in the syntax doc where each of these lines are given.
> 
> As for the results, the thread display is (for example):
> 
> T00001: Computer, Wed 29 Aug 12. (1). Problem
> 
> However, what I get at the top of the text box in starting a new entry or replying to a previous one is
> 
> [Wed 29 Aug 12]
> 
> whereas I expected to get
> 
> [29 Aug]
> 
> Putting $date instead of $entry time in the Thread display line makes (the by now expected) no difference
> 
> I cannot see where I'm going wrong.  
> 
> TIA 
> 
> David.

 Hi Garret,

Why cannot you just use $entry time ?  It uses the date that the entry was made which appears as the first line of every elog entry -

[Sorry for mis-post, just discovered cannot put the 'dollar at' control set in an entry]

MID: 12458
Date: Fri, 07 Sep 2012 17:22:06 +0100
In reply to: 12453
 

You can use 'Time format = ' to get the date to display in the format you like.  You will see I have posted an issue about 'Date format = '.  I mention this because in trying to understand what was happening, I too had a case where all the dates were showing as the same in a thread.  I suspect your 12/31/1969 was due to the entries as being read were non-existant or blank.

Of course I may have mis-understood your requirements.

I upgraded my system, including the version of Firefox.

I normally view the topic in Threaded Collapsed mode, right click on the entry I want to reply to, to open a new
Tab.  However, I made a mistake an opened a new Window, as the two 'open' modes in Firefox swapped around.
But no worry, I thought, made my reply as usual.

However, when refreshing the topic afterwards, seemingly randomly distributed throughout the topic were
additional lines, with the latest entry showing up emboldened (but not as a clickable link), and the only
difference being the ID number which showed as 0 (zero).

Deleting the reply only caused the previous reply to show up randomly etc.

In effect, the latest entry is (randomly?) scattered throughout the topic - even in between entries older than
any in that thread, so it's not individial entries in that thread showing up.

The only way to get rid of it was to erase the whole directory, and re-install from backup (which, as it was the
first entry since the new installation, wasn't painful).  It's been fine since - but only so long as I open a
thread in a new tab, and not in a new Window.

I guess the real question is just what is added to some file - perhaps the .cfg file? - that using a separate
window causes this behavioir?  Any whay only as a new window, and given how elog is supposed to work on many
computers, why on this stand-alone computer running two sets of the same browser?

It happened once before at the end of last year during a regression backwards owing to the newer computer
failing and turning back to an older one with older OS and older firefox, where I did the same thing (in
reverse).  As I didn't investigate at that time, I still have the mystery line showing up in that topic.

Sorry this is a bit rambling, but its very hard to describe!

> > I upgraded my system, including the version of Firefox.
> > [...]
> > Sorry this is a bit rambling, but its very hard to describe!
> 
> A picture can say more than thousand words.
> Can you reproduce this with a simple configuration?
> If yes, can you attach the configuration, the *a.log files,
> a description of what firefox version you're using and please:
> some screenshots of "before" and "after"?
> 
> Thanks!
> Andreas
That's odd, I cannot reproduce the problem today - except on the topic [logbook] it already exists on.
Yet nothing has changed.  
I've looked for hidden files, hidden control codes in the *a.log files...  this one had better be put on the
back burner until I can find a way to reproduce it (!).

Philippe Rousselot wrote:

Philippe Rousselot wrote: Andreas Luedeke wrote: Philippe Rousselot wrote: Bonjour, tout est dans le titre. Merci For those who speak strange languages, I asked how to get a french version of elog. By the way, this is my second mail because I forgot to give an icon to the first mail, and when I hit Back to do so, my text was erased. Bug or normal obnoxious attitude of my browser ? Thanks in advance Philippe  ELOG comes "internationalised": you just need to set your desired language in the configuration files. Language = french in the configuration file elogd.cfg does the trick. If you are capable to read the English language (which I suppose ), then I would recommend reading the manual, e.g. https://midas.psi.ch/elog/config.html#global Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English   PS: I happened to have the same problem (text erased after "back") when I had javascript disabled in the browser. If you have it enabled, you'll get a popup window that tells you what mandatory fields are missing in your post. Then you'll not need to use the back button.  Hi, Thanks for the answer. I tried this (directly from de setting menu in the demo account as well as from the onfig file) : I modified of course the text that could be modified directly from there such as menus and submenus. I added Language = french, I restarted the server, clear the cache of firefox (IE as well), but list, new and so on appear in english even they are in the locale file... Indeed, the manual is very interesting concerning javascript, it is activated ... Thanks again Philippe  Found it !   I wanted to have locale set in the folder demo (so I could have one in french and one in english). Once language set in globals everything went fine. Almost... Philippe

 May I make a suggestion here?  Something I do for other reasons.  I run two separate elog daemons, each with their own configuration files.  In this case you could have one configuration file tout en française, and the other in English.  This gets around the language setting being in the Global section of the configuration file elog.cfg

Of course this needs a little planning, for example a small script/batch file to start up each daemon with the correct config file. - so on my linux system, I start one with

/usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd0.cfg -d /home/logbooks

and the other with

/usr/local/sbin/elogd -p 8081 -c /home/logbooks/elogd1.cfg -d /home/logbooks

 

The disadvantage is that you cannot click between French and English by the tabs along the top of the elog page, you'd have to switch between browser windows.

Hope this helps.

David.

Andreas Luedeke wrote:

David Pilgram wrote: [...] [...]  May I make a suggestion here?  Something I do for other reasons.  I run two separate elog daemons, each with their own configuration files.  In this case you could have one configuration file tout en française, and the other in English.  This gets around the language setting being in the Global section of the configuration file elog.cfg Of course this needs a little planning, for example a small script/batch file to start up each daemon with the correct config file. - so on my linux system, I start one with /usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd0.cfg -d /home/logbooks and the other with /usr/local/sbin/elogd -p 8081 -c /home/logbooks/elogd1.cfg -d /home/logbooks The disadvantage is that you cannot click between French and English by the tabs along the top of the elog page, you'd have to switch between browser windows. Hope this helps. David. Does this work nice and stable for you? I've tried at the beginning to run two server on one host, one in German and the other in English. I experienced occasional server crashes (every few days) and assumed that they were related to two mirrors running on the same host. A mirror server just for a second language was not of big importance to me, therefore I did shut down the mirror server. And the server stopped crashing then. Was that just coincidence? I recognised that you are not running a mirror, you let both logbook processes access the same data. Is that save? Did you ever see data corruption from two processes modifying the same data? Or is one of the ELOG servers not used much?   Thanks for sharing your experience! Andreas   Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English

 I'd better put some caveats in here, then!

The two daemons on my host were never accessing the same subdirectories of /home/logbooks (this is my location, for ease of data backups (*)), and they were running with owner 'nobody', i.e. that's the owner of each directory.  In that sense they were independant, and as I was the only user, only one daemon would be working on files at any one moment. 

Next is that my system is never running for so many days uninterrupted.  The computer sometimes has to be booted into Windoze to use the CAD program, or even was just shut down and switched off.

I realise now that my earlier reply may have lead people to think they could work on the same data with two separate daemons (so as to work in their own language, but the data would be in both....) but I never meant to give that impresssion.  I've simply not tried it.  It might work on a stand-alone system, but I don't know how elog copes with multiple users accessing data at the same time - lock files?  check to see if data has been altered before allowing a submission is probably not done (it would make a branch if branches were allowed, I think) - I don't have the experience of using elog under these circumstances.  I thought Philippe Rousselot wanted a French language logbook and a separate English language one.  If I'm wrong there, sorry to raise his hopes.

Make a nice little project for someone to explore the limits, and maybe find what changes are needed.  Not necessarily to impliment it, though.

As for data corruption, never seen any, but I suppose the general warning of keep the backups well up-to-date.  I have had trouble with data, in particular moving data between logbooks, and this is one reason I have experience of how to make an elog entry using a text editor, as well as how to modify entries - to assemble scattered entries into a thread, or split a long thread into two shorter ones for ease of handling.  But I don't think those were ever connected to having two deamons running on one host, it happens when just one is running.

(*) In principle, all my data can be put on a memory stick - currently 16GB - and then I can run any linux box with full access to all my data, with the memory stick mounted on /home.

When I saw this problem come in, I was reminded of problems I have of elog crashing.  So I tried attaching a .bmp file to an entry.  In my case it did not crash, but it did not run ImageMagick either - it just gave a link as it it were a zip or tar file - that is to say no .png image had been generated and shown.   As I've never attached a .bmp file before, I don't know whether elog allows for them to be processed and a thumbnail made, a quick look in the documentation didn't enlighten me, but then I didn't look for that long either.  (I'm running 2.9.2 svn 2475, under Slackware 13 which is a version post some image processing issues I reported to Stefan - might that explain why in my case?). 

I have found that sometimes elog will crash, but effectively after it has done the action - so if it crashes when asked to move files from one logbook to another, you find the entries have been moved.  In my case, I believe the crashes are due to memory issues, nothing I can state for certain.

It would possibly help Stefan and Andreas if you can tell whether the .bmp file appears in the relivent logbook directory (usually a subdirectory of ....../logbooks) - it will have been renamed as yymmdd_hhmmss_{filename}.bmp - except, of course, the date and time will be showing not these symbols - and if the entry with which you have tried to attach this .bmp file been written - using a text viewer on the file yymmdda.log (obviously the day will be today, i.e. the one just updated as you tried the entry.   I have come across orphan attachment files in directories in my time, possibly from when elog crashed part way through an action.

(If I am stating the obvious, apologies, I don't know your level of experience with elog or linux, so trying to cover all possible levels)