Asked  2 Months ago    Answers:  5   Viewed   6 times

Go's time package claims giving a nanosecond precision. http://golang.org/src/pkg/time/time.go

I'm wondering how it is implemented and if I can trust it. My doubts come from Python, which clearly documents its difficulties and limitations with time:

From http://docs.python.org/2/library/time.html

The precision of the various real-time functions may be less than suggested by the units in which their value or argument is expressed. E.g. on most Unix systems, the clock “ticks” only 50 or 100 times a second.

On the other hand, the precision of time() and sleep() is better than their Unix equivalents: times are expressed as floating point numbers, time() returns the most accurate time available (using Unix gettimeofday() where available), and sleep() will accept a time with a nonzero fraction (Unix select() is used to implement this, where available).

Since the operating systems are giving such a hard time to python, how does Go achieve its nanosecond precision?

 Answers

25

Well as for the implementation, time.Now() falls back to a function implemented in the runtime. You can review the C time implementation and the implementation for time·now in assembly (linux amd64 in this case). This then uses clock_gettime, which provides nano seconds resolution. On windows, this is realized by calling GetSystemTimeAsFileTime, which too generates nanoseconds (not as high res but nanoseconds).

So yes, the resolution depends on the operating system and you can't expect it to be accurate on every OS but the developers are trying to make it as good as it can be. For example, in go1.0.3, time·now for FreeBSD used gettimeofday instead of clock_gettime, which only offers millisecond precision. You can see this by looking at the value stored in AX, as it is the syscall id. If you take a look at the referenced assembly, you can see that the ms value is mulitplied by 1000 to get the nanoseconds. However, this is fixed now.

If you want to be sure, check the corresponding implementations in the runtime source code and ask the manuals of your operating system.

Sunday, August 22, 2021
 
hakre
answered 2 Months ago
33
private final static int DELAY = 10000;
private final Handler handler = new Handler();
private final Timer timer = new Timer();
private final TimerTask task = new TimerTask() {
    private int counter = 0;
    public void run() {
        handler.post(new Runnable() {
            public void run() {
                Toast.makeText(MainActivity.this, "test", Toast.LENGTH_SHORT).show();
            }
        });
        if(++counter == 4) {
            timer.cancel();
        }
    }
};

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    timer.schedule(task, DELAY, DELAY);
}
Thursday, August 5, 2021
 
Sunny Shah
answered 3 Months ago
99

Below example is for BigQuery Standard SQL

#standardSQL
WITH `project.dataset.yourtable` AS (
  SELECT 'Pacific/Honolulu' timezone, TIMESTAMP '2020-03-01 03:41:27 UTC' UTC_timestamp UNION ALL
  SELECT 'America/Los_Angeles',  '2020-03-01 03:41:27 UTC'
)
SELECT *, 
  DATETIME(UTC_timestamp, timezone) AS local_time
FROM `project.dataset.yourtable`

with output

Row timezone            UTC_timestamp           local_time   
1   Pacific/Honolulu    2020-03-01 03:41:27 UTC 2020-02-29T17:41:27  
2   America/Los_Angeles 2020-03-01 03:41:27 UTC 2020-02-29T19:41:27  
Thursday, September 2, 2021
 
gMale
answered 2 Months ago
45

It's common for many kind of simple values.

In Go, when some value isn't bigger than one or two words, it's common to simply use it as a value instead of using a pointer. Simply because there's no reason to use a pointer if the object is small and you don't pass it to be changed.

You might have to unlearn the practice of languages where everything structured couldn't be handled as values. It's probably natural for you to use integers or floating point numbers as values, not pointers. Why not do the same for times ?

Regarding your precise problem with JSON and assuming you don't want to write a specific Marshaller just for this, there's no problem in using a *time.Time. In fact this issue was already mentioned in the golang-nuts list.

Wednesday, September 29, 2021
 
Lloydworth
answered 3 Weeks ago
22

Use indexTZ<- and the America/New_York timezone

> tail(SPY)
                    SPY.Bid.Price SPY.Ask.Price SPY.Trade.Price SPY.Mid.Price SPY.Volume
2012-08-09 19:54:00        140.47        140.48          140.48       140.475       2372
2012-08-09 19:55:00        140.46        140.47          140.46       140.465       5836
2012-08-09 19:56:00        140.47        140.48          140.48       140.475       2538
2012-08-09 19:57:00        140.47        140.48          140.47       140.475       2209
2012-08-09 19:58:00        140.48        140.49          140.49       140.485       4943
2012-08-09 19:59:00        140.58        140.59          140.58       140.585      16780
> indexTZ(SPY) <- "America/New_York"
> tail(SPY)
                    SPY.Bid.Price SPY.Ask.Price SPY.Trade.Price SPY.Mid.Price SPY.Volume
2012-08-09 15:54:00        140.47        140.48          140.48       140.475       2372
2012-08-09 15:55:00        140.46        140.47          140.46       140.465       5836
2012-08-09 15:56:00        140.47        140.48          140.48       140.475       2538
2012-08-09 15:57:00        140.47        140.48          140.47       140.475       2209
2012-08-09 15:58:00        140.48        140.49          140.49       140.485       4943
2012-08-09 15:59:00        140.58        140.59          140.58       140.585      16780
Warning message:
timezone of object (America/New_York) is different than current timezone (GMT). 
Thursday, October 14, 2021
 
the Tin Man
answered 3 Days ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :