missing casacore log in carta.log

[kswang1029]

Describe the bug
in the backend console we can see casacore log as well as carta log. Example is

[2022-08-03 07:16:23.583] [CARTA] [debug] Updated 1 preferences
[2022-08-03 07:16:23.595] [CARTA] [info] 0x7fee87f04080 ::Session (44930244:1)
[2022-08-03 07:16:23.595] [CARTA] [info] Session 44930244 [127.0.0.1] Connected. Num sessions: 1
2022-08-03 07:16:37 INFO FITSCoordinateUtil::fromFITSHeader passing empty or nonexistant spectral Coordinate axis
2022-08-03 07:16:37 INFO FITSCoordinateUtil::fromFITSHeader passing empty or nonexistant spectral Coordinate axis
2022-08-03 07:16:37 INFO FITSCoordinateUtil::fromFITSHeader passing empty or nonexistant spectral Coordinate axis
2022-08-03 07:16:39 INFO FITSCoordinateUtil::fromFITSHeader passing empty or nonexistant spectral Coordinate axis
[2022-08-03 07:16:38.876] [CARTA] [warning] Session 44930244: Image has no beam information.
[2022-08-03 07:16:38.970] [CARTA] [debug] Updated 1 preferences

However, it appears that casacore log is missing in the carta.log file.

In addition, it would be good to have consistent format to show casacore log (with brackets).

Platform info (please complete the following information):

• OS [e.g. macOS Monterey]: macOS Monterey
• Browser [e.g. chrome, safari, electron app]: chrome
• Browser version [e.g. 22]: 103
• Backend branch [e.g. dev, v3b2 release]: dev
• Frontend branch [e.g. dev, v3b2 release]: dev

[confluence]

@jolopezl changing the casacore log format may be more complicated than adding the missing messages -- I don't think it should be a prerequisite for completing this issue. Please feel free to create a separate issue for that if it becomes necessary.

[confluence]

When we look at this again, I would like to revisit the decision made in #1168 to use UTC for all the logs (for consistency, because the casacore logs are in UTC). This can be very confusing when the server is in a time zone only a few hours off from UTC (like South African time, UTC+2), because it can be non-obvious that the time is in UTC (especially when this is unexpected, because other logs are using local time).

I think it would be beneficial to restore the use of local time, or at least make this a configurable option -- I understand that this depends on a casacore change, so maybe this could be investigated at the same time as the casacore log format.

[kswang1029]

When we look at this again, I would like to revisit the decision made in #1168 to use UTC for all the logs (for consistency, because the casacore logs are in UTC). This can be very confusing when the server is in a time zone only a few hours off from UTC (like South African time, UTC+2), because it can be non-obvious that the time is in UTC (especially when this is unexpected, because other logs are using local time).

I think it would be beneficial to restore the use of local time, or at least make this a configurable option -- I understand that this depends on a casacore change, so maybe this could be investigated at the same time as the casacore log format.

If that is the case, I would suggest that for UDM builds, it can be using local time (but there is daylight saving time difference in the US and Europe). For SDM, it is still in UTC as a user may have multiple access of SDM CARTA at different places. For simplicity, however, a single UTC all for both UDM and SDM is still better in my opinion. We probably just need to make it clear that the displayed timestamps is UTC.

[confluence]

We can't distinguish between UDM and SDM at build time. This should be configurable dynamically through the config file -- then users or sysadmins will be able to set it up however they like (I think that local time is a sensible default).

I'm not sure that I follow why it's a problem for users to have different timezones in the logs of different SDM instances. These logs are stored on the server, and are likely to be read by system administrators trying to debug issues. So it's more important for them to be in sync with other logfiles on the server than for them to have a consistent timezone across servers from any particular user's point of view. If the user reports an issue and mentions a specific time, it will probably be in their local time, which is not the same timezone as the current UTC solution, and will require a conversion by the sysadmin anyway (there's no way to avoid this). If a user reports a problem that is happening "now", the sysadmin is likely to see that report timestamped with their own local time.

[pford]

The ISO 8601 standard appends a Z to the timestamp to indicate the "zone designator for the zero UTC offset" (https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC)), so I used this time format for the log messages to indicate it is not local time. I also added a leading [casacore] tag to the log message so the entry would be (unfortunately a spelling error in casacore in this example):
[2023-09-29 15:36:58.145Z] [info] [casacore] passing empty or nonexistant spectral Coordinate axis

I will open a PR, please let me know if this format is acceptable.

[confluence]

That sounds good to me.