Use Dear timezone for the time zone that time stamps are shown in on document history
Every Dear instance is set to a timezone. However the time stamp of Activity History on for example a sales order is shown in the local time zone of the user, as informed by the user's browser. The Activity History does not show the time zone of the time stamp.
This is very confusing. For instance, two users looking at the same screen and the same activity history see different times. Without any hint about what timezone the number is in, the is extremely open to misinterpretation. Also, it leaves a user vulnerable to their browser making a mistake about its timezone. This is an issue for me in Australia supporting clients in the UK. Worse, many Dear users travel ... that's one of the reasons they like cloud software. It must be very confusing to keep track of being in Hong Kong and talking to London users back at the office, having to (a) notice that your time stamps are now in HK time and (b) converting back to the UK timezone, remembering to adjust for summer time etc.
At a minimum, Dear should show the timezone it is using when presenting dates, so at least someone is aware of what the timestamp means.
My expectation is the time stamps should be in the timezone of Dear's settings, so that a user roaming from head office still sees the same information as if they were back at the desk in the office.
I am just about to set up a new client on Dear and this will be the first one with different locations is caring time zones. This will be an issue if the date stamp is not consistent and yes as a minimum if it's the same as the main Dear account that would at least give some consistancy.
the time stamp in the system is always in UTC, so there is no technical issue. This is just a cosmetic issue, but it is very annoying for something so easily fixed.
My point is just that presentation of the timestamp is confusing. It is a bit insane to show a timestamp without showing the timezone, particularly when the timezone is not UTC nor the timezone in the settings of Dear. This qualifies as a nasty surprise, in my opinion.
I should clarify this. Some 'timestamps' in Dear behave differently. Sales get an Order Date timestamp of 'new day', which is based on Dear system time zone. There are no seconds used. So all orders entered on Dec 25 have an order date of 2020-12-25 00:00 to the local user, even if they are entered at 9am or 2pm.
Imagine there is a Dear entity in New Zealand, UTC+12, and a second entity in London (UTC+0). That is, two separate systems.
Imagine a customer calls simultaneously to both countries to place on order with each Dear entity, so that it is 11pm in London on Dec 25. It is 11am the 'next day' in NZ.
Obviously the UTC time is the same, but the order date will be Dec 25 in the UK and Dec 26 in NZ. This makes sense. It means a manager wanting to see Boxing Day sales (Dec 26) is going to see sales on Dec 26 in the local time, but the manager needs to wait until close of business in the UK before consolidating both sales results. (I know about this since I take a feed of multiple Dear instances into Zoho Analytics)
If you actually have one system with timezone set to be UK but with users in NZ and the UK, then both orders will be in the same system, and they are both dated based on the the time in London. That is, both orders would have an order date of 2020-12-25 00:00
It bears pointing out/repeating that the lack of a recorded time of sale, not just the date of sale (even when pushing orders by the API!), is utterly bizarre behaviour by DEAR and creates all sorts of issue when later dealing with sales data.
Just recently I have had to implement an order view sorting mechanism that now uses the sale order number with the SO- stripped off to sort sales, because unlike just about every other system in existence DEAR just totally ignores the time of day part of a correctly supplied UTC date so you can't use the most logical field to sort sales from oldest to newest.