Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Paranoid date time question

    The following article recommends a way to include a timestamp into the output:
    https://www.stata.com/support/faqs/d...date-and-time/

    It relies on the two calls to obtain date and time separately.

    If the time is close to 23:59:59... on Jan 1 theoretically it is possible that the date evaluates to Jan 1, then the clock ticks, and the time evaluates already to 00:00:00 (for the new date Jan 2), resulting in a timestamp 24 hours away from the actual instant.

    This problem would not happen if Stata had a method to return the current timestamp (a combination of current Date and Time), from which the necessary components could have been extracted, but I don't see any.

    I believe that this is rather paranoid, but I would still want to record the timestamp correctly. Any advice?

    Thank you, Sergiy

  • #2
    Maybe

    1. call the operating system (-shell-) to pipe its timestamp into the log file (not sure if Stata locks the open log file from other processes, though)

    or

    2. put a call into whatever RDBMS (-odbc-) you're using to get the timestamp from it

    or

    3. (not applicable to batch mode execution) low-tech, but higher personal health value: try to avoid working so late into the evening


    (3 is not intended to be tongue-in-cheek.)

    Comment


    • #3
      I think the following code demonstrates a workable approach.
      Code:
      . local t1 `c(current_time)'
      
      . local d1 `c(current_date)'
      
      . local t2 `c(current_time)'
      
      . local d2 `c(current_date)'
      
      . local ts `d1' `t1'
      
      . if "`t2'" < "`t1'" {
      .     local ts `d2' `t2'
      .         }
      
      . display "`ts'"
      9 Jun 2018 07:33:56
      
      . // test other case manually
      . local t2 00:00:01
      
      . local d2 10 Jun 2018
      
      . if "`t2'" < "`t1'" {
      .     local ts `d2' `t2'
      .         }
      
      . display "`ts'"
      10 Jun 2018 00:00:01

      Comment


      • #4
        Thank you very much Joseph and William,

        both approaches are valid. To summarize, Joseph's suggestion is (realizing the absence of the needed function in Stata) to call the OS or another service that may provide such a timestamp. This may run into OS dependency/compatibility problems later on. Unfortunately DOS (and hence Windows) suffers from the same problem as Stata, the default commands to obtain the date and time are working separately:
        Code:
        ECHO %DATE%
        ECHO %TIME%
        But there is no shortage of utils and API functions to obtain the real timestamp or number of ticks since the PC is started, since the beginning of time, etc. (or use plugins to read that using C API calls).

        William's approach is more portable, and is based on the fact that even if the undesirable clock adjustment happens, it is going to be detectable, and hence correctable (time flows only one direction, hence within a sequence of timestamps each must be larger than the previous, and if observed otherwise, it is erroneous and the next one should be preferred). So with a series of reads (at least 2) one can come up with a reliable timestamp. I've had a version of this that waits for 1msec between the two clock reads, but at the moment can't come up with an example of why that was necessary.

        Again, thank you very much. Sergiy

        Comment

        Working...
        X