Folding Forum

While I can understand the desire to have everyone using the same time standard, it would be useful when troubleshooting to have an occasional entry in the log file indicating the local time in addition to the UTC time. For example, could the line:

--- Opening Log file [May 6 02:06:25 UTC]

be changed to:

--- Opening Log file [May 6 02:06:25 UTC, May 5 20:06:25 MDT]

I'm not sure that's possible to give you exactly what you requested. FAH's code is written to run on Windows/Linux/MacOS and insofar as possible, uses API calls that are recognized by all OSs and which most likely conform to international standards. I'm reasonably sure that ll operating systems have an API call which will report the UTC date-time and an offset to your local timezone, but I wonder if they all provide and API call that will report whether an offset of -6 is MDT or CST?

V7 has already been changed to conform to ISO standard date-time rather than the way you show it. It seems unlikely that they'll change it back to a non-standard format.

For those who have trouble with times, perhaps the 24 hour clock is also a problem. Perhaps you'll be happy with:

--- Opening Log file [2012-05-06T02:06:25Z, Local time: May 5 8:06 PM ]

You should be aware that the data is already shown in the log, although you'll need to subtract. The date-time at the top of the log conforms to ISO standards and your local offset is shown several lines later. ISO 8601 is also used to display the download and deadline data in FAHControl.

*********************** Log Started 2012-05-05T04:03:59Z ***********************
04:03:59:************************* Folding@home Client *************************
04:03:59: Website: http://folding.stanford.edu/
04:03:59: Copyright: (c) 2009-2012 Stanford University
04:03:59: Author: Joseph Coffland <[email protected]>
04:03:59: Args:
04:03:59: Config: C:/Users/bruce/AppData/Roaming/FAHClient/config.xml
04:03:59:******************************** Build ********************************
04:03:59: Version: 7.1.51
04:03:59: Date: Mar 15 2012
04:03:59: Time: 14:21:34
04:03:59: SVN Rev: 3281
04:03:59: Branch: fah/trunk/client
04:03:59: Compiler: Intel(R) C++ MSVC 1500 mode 1200
04:03:59: Options: /TP /nologo /EHa /Qdiag-disable:4297,4103,1786,279 /Ox -arch:SSE
04:03:59: /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2 /Qopenmp /Qrestrict /MT
04:03:59: Platform: win32 XP
04:03:59: Bits: 32
04:03:59: Mode: Release
04:03:59:******************************* System ********************************
04:03:59: CPU: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
04:03:59: CPU ID: GenuineIntel Family 6 Model 23 Stepping 10
04:03:59: CPUs: 4
04:03:59: Memory: 8.00GiB
04:03:59: Free Memory: 6.42GiB
04:03:59: Threads: WINDOWS_THREADS
04:03:59: On Battery: false
04:03:59: UTC offset: -7
04:03:59: PID: 4548

A story (and a little suggestion):

When I was first learning to fly, my flight instructor was explaining the standard "lingo" that pilots and ATC use to communicate on the radio. For obvious reasons, all times are given in UTC ("Zulu") even if I never flew beyond California/Arizona. I already knew that CA was either UTC-8 (winter) or UTC-7 (summer) and AZ was always UTC-7. After that lesson had been thoroughly learned (on the ground) I realized that in the air, many communications are time-zone independent --- just like when you're watching a live nationwide or worldwide TV show. ATC will say something like "Expect further clearance at 12 minutes past the hour" in cases where it is clear that they're talking about the next time it's 12 minutes after some hour, no matter what number was assigned to that hour. Just mentally take the hour hand off your clock.

With respect to FAH's log, you can often ignore the time-zone completely by just looking at the minutes. Of course that doesn't ALWAYS work, but try it anyway and it often will.

bruce wrote: A story (and a little suggestion):

When I was first learning to fly, my flight instructor was explaining the standard "lingo" that pilots and ATC use to communicate on the radio. For obvious reasons, all times are given in UTC ("Zulu") even if I never flew beyond California/Arizona. I already knew that CA was either UTC-8 (winter) or UTC-7 (summer) and AZ was always UTC-7. After that lesson had been thoroughly learned (on the ground) I realized that in the air, many communications are time-zone independent --- just like when you're watching a live nationwide or worldwide TV show. ATC will say something like "Expect further clearance at 12 minutes past the hour" in cases where it is clear that they're talking about the next time it's 12 minutes after some hour, no matter what number was assigned to that hour. Just mentally take the hour hand off your clock.

With respect to FAH's log, you can often ignore the time-zone completely by just looking at the minutes. Of course that doesn't ALWAYS work, but try it anyway and it often will.

Your story shows why UTC is a good thing for communications between entities that are geographically separated and I am well aware of how time-zones and in particular, daylight savings time can cause lots of confusion. I ran a weekly event that had participents from Europe, North America, and Australia. Every year around March-April and October-November my Australian friend would miss an event because both North America and Australia have daylight savings in place but just like flushing toliets, they go in opposite directions. Add to that the politics of picking the change dates and you can see the confusion that might arise.

On the other hand, my computer(s) and all of the processes that run on it(them) tend to be very stationary. They all (Windows and Linux) very prominently display local time and can also tell me UTC. One could argue that using local time in the logs would be just as useful as UTC because the logs aren't being shared, the folding output is being shared. When I'm troubleshooting a local problem, I find it easier to corrolate local events with local time.

I have to admit, however, I did miss the UTC offset line in the logs and that may be good enough although the change I'm asking for (let the computer do the math) is pretty trivial and yes, I'd accept an OS neutral, standards based solution.

I have to disagree. The log is highly portable. People from all over the world post their logs here and expect someone like me to fine the last WU they uploaded. Sometimes I can deduce what time it is where they are, but since the log is always in UTC, I don't need to do that. Timestamps in your log match same timestamps in my log even though we're geographically separated -- and that even works if one of us is on daylight savings time and the other isn't. (Even London has British Summer Time although not at the observatory in Greenwich.)