Date format in audit trail

Date format is not the same in Audit Trail as defined in Preferences. Can you please look into this?

image

image

@lubos Can you look into this. It can be confusing to work with a date format that is US format instead of UK format. We work in day, month and year, not month, day year format. I agree that that the audit trail should use the format set in preferences. Thanks

This was addressed here: Date format under History

Fair enough. Not sure why the javascript would have anything to do with it, but if he says it can’t be done, then that’s ok, It’s not the end of the world.

@dalacor Manager stores timestamps in UTC format. This is because people can be working in Manager across multiple timezones. Javascript is useful because it can convert UTC time to local time based on your operating system settings. Manager doesn’t know your timezone (unless you are using desktop edition) and I’m reluctant to add new field to ask for timezone info just to improve the look of single screen.

However, I realized there is getTimezoneOffset() function in javascript so perhaps date format on history screen could be implemented properly. I’ll put this into ideas because now I see how it could be done.

Thank you. I fully agree with you that it does not make sense to develop a new field just to improve look of one screen. I had not realised that the audit trail was in UTC format but what you say makes sense. If it can be sorted, that’s great, but equally fine if not doable as it’s not that important in the greater scheme of things.

Most applications I use ask in preferences to set the timezone in addition to date format, so really do not see the issue to implement this and would take away the confusion. If anything it would ensure consistency throughout the way dates are displayed which is the purpose of he date format settings in preferences as well. So please implement as dates also in history are undeniably a core component of book keeping and accounting (history can help audit as well). That one can “cope” with it is in essence a blemish on an otherwise well developed application. I noticed only with lots of pressure / pushback from users that code may be considered but in this case it is more a case of consistency that is recognized but not addressed. Maybe people do not use other people to work on the accounts but when they do the history check is almost a daily task, especially when some data seem to have changed to unlikely values and knowing who changed what when helps tremendously isolating the error. Confusing date formats where months and days are in reverse pending geography is in any case a global cock-up but fortunately programmatic solutions exist that can ensure more consistency. The appeal here is to implement these.