Namespace: go.std.time
v1.0Contents
Summary
Provides a low-level interface to the time package.
Package time provides functionality for measuring and displaying time.
The calendrical calculations always assume a Gregorian calendar, with
no leap seconds.
Monotonic Clocks
Operating systems provide both a “wall clock,” which is subject to
changes for clock synchronization, and a “monotonic clock,” which is
not. The general rule is that the wall clock is for telling time and
the monotonic clock is for measuring time. Rather than split the API,
in this package the Time returned by time.Now contains both a wall
clock reading and a monotonic clock reading; later time-telling
operations use the wall clock reading, but later time-measuring
operations, specifically comparisons and subtractions, use the
monotonic clock reading.
For example, this code always computes a positive elapsed time of
approximately 20 milliseconds, even if the wall clock is changed during
the operation being timed:
start := time.Now()
... operation that takes 20 milliseconds ...
t := time.Now()
elapsed := t.Sub(start)
Other idioms, such as time.Since(start), time.Until(deadline), and
time.Now().Before(deadline), are similarly robust against wall clock
resets.
The rest of this section gives the precise details of how operations
use monotonic clocks, but understanding those details is not required
to use this package.
The Time returned by time.Now contains a monotonic clock reading.
If Time t has a monotonic clock reading, t.Add adds the same duration to
both the wall clock and monotonic clock readings to compute the result.
Because t.AddDate(y, m, d), t.Round(d), and t.Truncate(d) are wall time
computations, they always strip any monotonic clock reading from their results.
Because t.In, t.Local, and t.UTC are used for their effect on the interpretation
of the wall time, they also strip any monotonic clock reading from their results.
The canonical way to strip a monotonic clock reading is to use t = t.Round(0).
If Times t and u both contain monotonic clock readings, the operations
t.After(u), t.Before(u), t.Equal(u), and t.Sub(u) are carried out
using the monotonic clock readings alone, ignoring the wall clock
readings. If either t or u contains no monotonic clock reading, these
operations fall back to using the wall clock readings.
On some systems the monotonic clock will stop if the computer goes to sleep.
On such a system, t.Sub(u) may not accurately reflect the actual
time that passed between t and u.
Because the monotonic clock reading has no meaning outside
the current process, the serialized forms generated by t.GobEncode,
t.MarshalBinary, t.MarshalJSON, and t.MarshalText omit the monotonic
clock reading, and t.Format provides no format for it. Similarly, the
constructors time.Date, time.Parse, time.ParseInLocation, and time.Unix,
as well as the unmarshalers t.GobDecode, t.UnmarshalBinary.
t.UnmarshalJSON, and t.UnmarshalText always create times with
no monotonic clock reading.
Note that the Go == operator compares not just the time instant but
also the Location and the monotonic clock reading. See the
documentation for the Time type for a discussion of equality
testing for Time values.
For debugging, the result of t.String does include the monotonic
clock reading if present. If t != u because of different monotonic clock readings,
that difference will be visible when printing t.String() and u.String().
Index
- *Duration
- *Location
- *Month
- *ParseError
- *Ticker
- *Time
- *Timer
- *Weekday
- ANSIC
- After
- AfterFunc
- April
- August
- Date
- December
- Duration
- February
- FixedZone
- Friday
- Hour
- January
- July
- June
- Kitchen
- Layout
- LoadLocation
- LoadLocationFromTZData
- Local
- Location
- March
- May
- Microsecond
- Millisecond
- Minute
- Monday
- Month
- Nanosecond
- NewTicker
- NewTimer
- November
- Now
- October
- Parse
- ParseDuration
- ParseError
- ParseInLocation
- RFC1123
- RFC1123Z
- RFC3339
- RFC3339Nano
- RFC822
- RFC822Z
- RFC850
- RubyDate
- Saturday
- Second
- September
- Since
- Sleep
- Stamp
- StampMicro
- StampMilli
- StampNano
- Sunday
- Thursday
- Tick
- Ticker
- Time
- Timer
- Tuesday
- UTC
- Unix
- UnixDate
- UnixMicro
- UnixMilli
- Until
- Wednesday
- Weekday
- arrayOfDuration
- arrayOfLocation
- arrayOfMonth
- arrayOfParseError
- arrayOfTicker
- arrayOfTime
- arrayOfTimer
- arrayOfWeekday
Legend
-
Constant
Variable
Function
Macro
Special form
Type
GoVar
Receiver/Method
Constants
Constants are variables with :const true in their metadata. Joker currently does not recognize them as special; as such, it allows redefining them or their values.-
ANSIC
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
Kitchen
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
Layout
String v1.0The reference time, in numerical order.
-
RFC1123
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
RFC1123Z
String v1.0RFC1123 with numeric zone
-
RFC3339
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
RFC3339Nano
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
RFC822
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
RFC822Z
String v1.0RFC822 with numeric zone
-
RFC850
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
RubyDate
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
Stamp
String v1.0Handy time stamps.
-
StampMicro
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
StampMilli
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
StampNano
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
-
UnixDate
String v1.0These are predefined layouts for use in Time.Format and time.Parse.
The reference time used in these layouts is the specific time stamp:
01/02 03:04:05PM '06 -0700
(January 2, 15:04:05, 2006, in time zone seven hours west of GMT).
That value is recorded as the constant named Layout, listed below. As a Unix
time, this is 1136239445. Since MST is GMT-0700, the reference would be
printed by the Unix date command as:
Mon Jan 2 15:04:05 MST 2006
It is a regrettable historic error that the date uses the American convention
of putting the numerical month before the day.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
Note that the RFC822, RFC850, and RFC1123 formats should be applied
only to local times. Applying them to UTC times will use "UTC" as the
time zone abbreviation, while strictly speaking those RFCs require the
use of "GMT" in that case.
In general RFC1123Z should be used instead of RFC1123 for servers
that insist on that format, and RFC3339 should be preferred for new protocols.
RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting;
when used with time.Parse they do not accept all the time formats
permitted by the RFCs and they do accept time formats not formally defined.
The RFC3339Nano format removes trailing zeros from the seconds field
and thus may not sort correctly once formatted.
Most programs can use one of the defined constants as the layout passed to
Format or Parse. The rest of this comment can be ignored unless you are
creating a custom layout string.
To define your own format, write down what the reference time would look like
formatted your way; see the values of constants like ANSIC, StampMicro or
Kitchen for examples. The model is to demonstrate what the reference time
looks like so that the Format and Parse methods can apply the same
transformation to a general time value.
Here is a summary of the components of a layout string. Each element shows by
example the formatting of an element of the reference time. Only these values
are recognized. Text in the layout string that is not recognized as part of
the reference time is echoed verbatim during Format and expected to appear
verbatim in the input to Parse.
Year: "2006" "06"
Month: "Jan" "January"
Textual day of the week: "Mon" "Monday"
Numeric day of the month: "2" "_2" "02"
Numeric day of the year: "__2" "002"
Hour: "15" "3" "03" (PM or AM)
Minute: "4" "04"
Second: "5" "05"
AM/PM mark: "PM"
Numeric time zone offsets format as follows:
"-0700" ±hhmm
"-07:00" ±hh:mm
"-07" ±hh
Replacing the sign in the format with a Z triggers
the ISO 8601 behavior of printing Z instead of an
offset for the UTC zone. Thus:
"Z0700" Z or ±hhmm
"Z07:00" Z or ±hh:mm
"Z07" Z or ±hh
Within the format string, the underscores in "_2" and "__2" represent spaces
that may be replaced by digits if the following number has multiple digits,
for compatibility with fixed-width Unix time formats. A leading zero represents
a zero-padded value.
The formats __2 and 002 are space-padded and zero-padded
three-character day of year; there is no unpadded day of year format.
A comma or decimal point followed by one or more zeros represents
a fractional second, printed to the given number of decimal places.
A comma or decimal point followed by one or more nines represents
a fractional second, printed to the given number of decimal places, with
trailing zeros removed.
For example "15:04:05,000" or "15:04:05.000" formats or parses with
millisecond precision.
Some valid layouts are invalid time values for time.Parse, due to formats
such as _ for space padding and Z for zone information.
Variables
-
April
GoObject v1.0 -
August
GoObject v1.0 -
December
GoObject v1.0 -
February
GoObject v1.0 -
Friday
GoObject v1.0 -
Hour
GoObject v1.0Common durations. There is no definition for units of Day or larger
to avoid confusion across daylight savings time zone transitions.
To count the number of units in a Duration, divide:
second := time.Second
fmt.Print(int64(second/time.Millisecond)) // prints 1000
To convert an integer number of units to a Duration, multiply:
seconds := 10
fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
-
January
GoObject v1.0 -
July
GoObject v1.0 -
June
GoObject v1.0 -
Local
Var v1.0Local represents the system's local time zone.
On Unix systems, Local consults the TZ environment
variable to find the time zone to use. No TZ means
use the system default /etc/localtime.
TZ="" means use UTC.
TZ="foo" means use file foo in the system timezone directory.
-
March
GoObject v1.0 -
May
GoObject v1.0 -
Microsecond
GoObject v1.0Common durations. There is no definition for units of Day or larger
to avoid confusion across daylight savings time zone transitions.
To count the number of units in a Duration, divide:
second := time.Second
fmt.Print(int64(second/time.Millisecond)) // prints 1000
To convert an integer number of units to a Duration, multiply:
seconds := 10
fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
-
Millisecond
GoObject v1.0Common durations. There is no definition for units of Day or larger
to avoid confusion across daylight savings time zone transitions.
To count the number of units in a Duration, divide:
second := time.Second
fmt.Print(int64(second/time.Millisecond)) // prints 1000
To convert an integer number of units to a Duration, multiply:
seconds := 10
fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
-
Minute
GoObject v1.0Common durations. There is no definition for units of Day or larger
to avoid confusion across daylight savings time zone transitions.
To count the number of units in a Duration, divide:
second := time.Second
fmt.Print(int64(second/time.Millisecond)) // prints 1000
To convert an integer number of units to a Duration, multiply:
seconds := 10
fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
-
Monday
GoObject v1.0 -
Nanosecond
GoObject v1.0Common durations. There is no definition for units of Day or larger
to avoid confusion across daylight savings time zone transitions.
To count the number of units in a Duration, divide:
second := time.Second
fmt.Print(int64(second/time.Millisecond)) // prints 1000
To convert an integer number of units to a Duration, multiply:
seconds := 10
fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
-
November
GoObject v1.0 -
October
GoObject v1.0 -
Saturday
GoObject v1.0 -
Second
GoObject v1.0Common durations. There is no definition for units of Day or larger
to avoid confusion across daylight savings time zone transitions.
To count the number of units in a Duration, divide:
second := time.Second
fmt.Print(int64(second/time.Millisecond)) // prints 1000
To convert an integer number of units to a Duration, multiply:
seconds := 10
fmt.Print(time.Duration(seconds)*time.Second) // prints 10s
-
September
GoObject v1.0 -
Sunday
GoObject v1.0 -
Thursday
GoObject v1.0 -
Tuesday
GoObject v1.0 -
UTC
Var v1.0UTC represents Universal Coordinated Time (UTC).
-
Wednesday
GoObject v1.0
Functions, Macros, and Special Forms
-
After
Function v1.0(After d)
After waits for the duration to elapse and then sends the current time
on the returned channel.
It is equivalent to NewTimer(d).C.
The underlying Timer is not recovered by the garbage collector
until the timer fires. If efficiency is a concern, use NewTimer
instead and call Timer.Stop if the timer is no longer needed.
Go input arguments: (d Duration)
Go returns: <-chan Time
Joker input arguments: [^Duration d]
Joker returns: ^chanRecvOfTime -
AfterFunc
Function v1.0(AfterFunc d f)
AfterFunc waits for the duration to elapse and then calls f
in its own goroutine. It returns a Timer that can
be used to cancel the call using its Stop method.
Go input arguments: (d Duration, f func())
Go returns: *Timer
Joker input arguments: [^Duration d, ^func f]
Joker returns: ^*Timer -
Date
Function v1.0(Date year month day hour min sec nsec loc)
Date returns the Time corresponding to
yyyy-mm-dd hh:mm:ss + nsec nanoseconds
in the appropriate zone for that time in the given location.
The month, day, hour, min, sec, and nsec values may be outside
their usual ranges and will be normalized during the conversion.
For example, October 32 converts to November 1.
A daylight savings time transition skips or repeats times.
For example, in the United States, March 13, 2011 2:15am never occurred,
while November 6, 2011 1:15am occurred twice. In such cases, the
choice of time zone, and therefore the time, is not well-defined.
Date returns a time that is correct in one of the two zones involved
in the transition, but it does not guarantee which.
Date panics if loc is nil.
Go input arguments: (year int, month Month, day int, hour int, min int, sec int, nsec int, loc *Location)
Go returns: Time
Joker input arguments: [^Int year, ^Month month, ^Int day, ^Int hour, ^Int min, ^Int sec, ^Int nsec, ^*Location loc]
Joker returns: ^Time -
FixedZone
Function v1.0(FixedZone name offset)
FixedZone returns a Location that always uses
the given zone name and offset (seconds east of UTC).
Go input arguments: (name string, offset int)
Go returns: *Location
Joker input arguments: [^String name, ^Int offset]
Joker returns: ^*Location -
LoadLocation
Function v1.0(LoadLocation name)
LoadLocation returns the Location with the given name.
If the name is "" or "UTC", LoadLocation returns UTC.
If the name is "Local", LoadLocation returns Local.
Otherwise, the name is taken to be a location name corresponding to a file
in the IANA Time Zone database, such as "America/New_York".
LoadLocation looks for the IANA Time Zone database in the following
locations in order:
- the directory or uncompressed zip file named by the ZONEINFO environment variable
- on a Unix system, the system standard installation location
- $GOROOT/lib/time/zoneinfo.zip
- the time/tzdata package, if it was imported
Go input arguments: (name string)
Go returns: (*Location, error)
Joker input arguments: [^String name]
Joker returns: [^*Location, ^Error] -
LoadLocationFromTZData
Function v1.0(LoadLocationFromTZData name data)
LoadLocationFromTZData returns a Location with the given name
initialized from the IANA Time Zone database-formatted data.
The data should be in the format of a standard IANA time zone file
(for example, the content of /etc/localtime on Unix systems).
Go input arguments: (name string, data []byte)
Go returns: (*Location, error)
Joker input arguments: [^String name, ^arrayOfByte data]
Joker returns: [^*Location, ^Error] -
NewTicker
Function v1.0(NewTicker d)
NewTicker returns a new Ticker containing a channel that will send
the current time on the channel after each tick. The period of the
ticks is specified by the duration argument. The ticker will adjust
the time interval or drop ticks to make up for slow receivers.
The duration d must be greater than zero; if not, NewTicker will
panic. Stop the ticker to release associated resources.
Go input arguments: (d Duration)
Go returns: *Ticker
Joker input arguments: [^Duration d]
Joker returns: ^*Ticker -
NewTimer
Function v1.0(NewTimer d)
NewTimer creates a new Timer that will send
the current time on its channel after at least duration d.
Go input arguments: (d Duration)
Go returns: *Timer
Joker input arguments: [^Duration d]
Joker returns: ^*Timer -
Now
Function v1.0(Now)
Now returns the current local time.
Go returns: Time
Joker input arguments: []
Joker returns: ^Time -
Parse
Function v1.0(Parse layout value)
Parse parses a formatted string and returns the time value it represents.
See the documentation for the constant called Layout to see how to
represent the format. The second argument must be parseable using
the format string (layout) provided as the first argument.
The example for Time.Format demonstrates the working of the layout string
in detail and is a good reference.
When parsing (only), the input may contain a fractional second
field immediately after the seconds field, even if the layout does not
signify its presence. In that case either a comma or a decimal point
followed by a maximal series of digits is parsed as a fractional second.
Fractional seconds are truncated to nanosecond precision.
Elements omitted from the layout are assumed to be zero or, when
zero is impossible, one, so parsing "3:04pm" returns the time
corresponding to Jan 1, year 0, 15:04:00 UTC (note that because the year is
0, this time is before the zero Time).
Years must be in the range 0000..9999. The day of the week is checked
for syntax but it is otherwise ignored.
For layouts specifying the two-digit year 06, a value NN >= 69 will be treated
as 19NN and a value NN < 69 will be treated as 20NN.
The remainder of this comment describes the handling of time zones.
In the absence of a time zone indicator, Parse returns a time in UTC.
When parsing a time with a zone offset like -0700, if the offset corresponds
to a time zone used by the current location (Local), then Parse uses that
location and zone in the returned time. Otherwise it records the time as
being in a fabricated location with time fixed at the given zone offset.
When parsing a time with a zone abbreviation like MST, if the zone abbreviation
has a defined offset in the current location, then that offset is used.
The zone abbreviation "UTC" is recognized as UTC regardless of location.
If the zone abbreviation is unknown, Parse records the time as being
in a fabricated location with the given zone abbreviation and a zero offset.
This choice means that such a time can be parsed and reformatted with the
same layout losslessly, but the exact instant used in the representation will
differ by the actual zone offset. To avoid such problems, prefer time layouts
that use a numeric zone offset, or use ParseInLocation.
Go input arguments: (layout string, value string)
Go returns: (Time, error)
Joker input arguments: [^String layout, ^String value]
Joker returns: [^Time, ^Error] -
ParseDuration
Function v1.0(ParseDuration s)
ParseDuration parses a duration string.
A duration string is a possibly signed sequence of
decimal numbers, each with optional fraction and a unit suffix,
such as "300ms", "-1.5h" or "2h45m".
Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".
Go input arguments: (s string)
Go returns: (Duration, error)
Joker input arguments: [^String s]
Joker returns: [^Duration, ^Error] -
ParseInLocation
Function v1.0(ParseInLocation layout value loc)
ParseInLocation is like Parse but differs in two important ways.
First, in the absence of time zone information, Parse interprets a time as UTC;
ParseInLocation interprets the time as in the given location.
Second, when given a zone offset or abbreviation, Parse tries to match it
against the Local location; ParseInLocation uses the given location.
Go input arguments: (layout string, value string, loc *Location)
Go returns: (Time, error)
Joker input arguments: [^String layout, ^String value, ^*Location loc]
Joker returns: [^Time, ^Error] -
Since
Function v1.0(Since t)
Since returns the time elapsed since t.
It is shorthand for time.Now().Sub(t).
Go input arguments: (t Time)
Go returns: Duration
Joker input arguments: [^Time t]
Joker returns: ^Duration -
Sleep
Function v1.0(Sleep d)
Sleep pauses the current goroutine for at least the duration d.
A negative or zero duration causes Sleep to return immediately.
Go input arguments: (d Duration)
Joker input arguments: [^Duration d] -
Tick
Function v1.0(Tick d)
Tick is a convenience wrapper for NewTicker providing access to the ticking
channel only. While Tick is useful for clients that have no need to shut down
the Ticker, be aware that without a way to shut it down the underlying
Ticker cannot be recovered by the garbage collector; it "leaks".
Unlike NewTicker, Tick will return nil if d <= 0.
Go input arguments: (d Duration)
Go returns: <-chan Time
Joker input arguments: [^Duration d]
Joker returns: ^chanRecvOfTime -
Unix
Function v1.0(Unix sec nsec)
Unix returns the local Time corresponding to the given Unix time,
sec seconds and nsec nanoseconds since January 1, 1970 UTC.
It is valid to pass nsec outside the range [0, 999999999].
Not all sec values have a corresponding time value. One such
value is 1<<63-1 (the largest int64 value).
Go input arguments: (sec int64, nsec int64)
Go returns: Time
Joker input arguments: [^BigInt sec, ^BigInt nsec]
Joker returns: ^Time -
UnixMicro
Function v1.0(UnixMicro usec)
UnixMicro returns the local Time corresponding to the given Unix time,
usec microseconds since January 1, 1970 UTC.
Go input arguments: (usec int64)
Go returns: Time
Joker input arguments: [^BigInt usec]
Joker returns: ^Time -
UnixMilli
Function v1.0(UnixMilli msec)
UnixMilli returns the local Time corresponding to the given Unix time,
msec milliseconds since January 1, 1970 UTC.
Go input arguments: (msec int64)
Go returns: Time
Joker input arguments: [^BigInt msec]
Joker returns: ^Time -
Until
Function v1.0(Until t)
Until returns the duration until t.
It is shorthand for t.Sub(time.Now()).
Go input arguments: (t Time)
Go returns: Duration
Joker input arguments: [^Time t]
Joker returns: ^Duration
Types
-
*Duration
Concrete Type v1.0A Duration represents the elapsed time between two instants
as an int64 nanosecond count. The representation limits the
largest representable duration to approximately 290 years.
-
*Location
Concrete Type v1.0A Location maps time instants to the zone in use at that time.
Typically, the Location represents the collection of time offsets
in use in a geographical area. For many Locations the time offset varies
depending on whether daylight savings time is in use at the time instant.
-
String
Receiver for *Location v1.0([])
String returns a descriptive name for the time zone information,
corresponding to the name argument to LoadLocation or FixedZone.
-
*Month
Concrete Type v1.0A Month specifies a month of the year (January = 1, ...).
-
*ParseError
Concrete Type v1.0ParseError describes a problem parsing a time string.
-
Error
Receiver for *ParseError v1.0([])
Error returns the string representation of a ParseError.
-
*Ticker
Concrete Type v1.0A Ticker holds a channel that delivers ``ticks'' of a clock
at intervals.
-
Reset
Receiver for *Ticker v1.0([d])
Reset stops a ticker and resets its period to the specified duration.
The next tick will arrive after the new period elapses. The duration d
must be greater than zero; if not, Reset will panic.
-
Stop
Receiver for *Ticker v1.0([])
Stop turns off a ticker. After Stop, no more ticks will be sent.
Stop does not close the channel, to prevent a concurrent goroutine
reading from the channel from seeing an erroneous "tick".
-
*Time
Concrete Type v1.0A Time represents an instant in time with nanosecond precision.
Programs using times should typically store and pass them as values,
not pointers. That is, time variables and struct fields should be of
type time.Time, not *time.Time.
A Time value can be used by multiple goroutines simultaneously except
that the methods GobDecode, UnmarshalBinary, UnmarshalJSON and
UnmarshalText are not concurrency-safe.
Time instants can be compared using the Before, After, and Equal methods.
The Sub method subtracts two instants, producing a Duration.
The Add method adds a Time and a Duration, producing a Time.
The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC.
As this time is unlikely to come up in practice, the IsZero method gives
a simple way of detecting a time that has not been initialized explicitly.
Each Time has associated with it a Location, consulted when computing the
presentation form of the time, such as in the Format, Hour, and Year methods.
The methods Local, UTC, and In return a Time with a specific location.
Changing the location in this way changes only the presentation; it does not
change the instant in time being denoted and therefore does not affect the
computations described in earlier paragraphs.
Representations of a Time value saved by the GobEncode, MarshalBinary,
MarshalJSON, and MarshalText methods store the Time.Location's offset, but not
the location name. They therefore lose information about Daylight Saving Time.
In addition to the required “wall clock” reading, a Time may contain an optional
reading of the current process's monotonic clock, to provide additional precision
for comparison or subtraction.
See the “Monotonic Clocks” section in the package documentation for details.
Note that the Go == operator compares not just the time instant but also the
Location and the monotonic clock reading. Therefore, Time values should not
be used as map or database keys without first guaranteeing that the
identical Location has been set for all values, which can be achieved
through use of the UTC or Local method, and that the monotonic clock reading
has been stripped by setting t = t.Round(0). In general, prefer t.Equal(u)
to t == u, since t.Equal uses the most accurate comparison available and
correctly handles the case when only one of its arguments has a monotonic
clock reading.
-
GobDecode
Receiver for *Time v1.0([data])
GobDecode implements the gob.GobDecoder interface.
-
UnmarshalBinary
Receiver for *Time v1.0([data])
UnmarshalBinary implements the encoding.BinaryUnmarshaler interface.
-
UnmarshalJSON
Receiver for *Time v1.0([data])
UnmarshalJSON implements the json.Unmarshaler interface.
The time is expected to be a quoted string in RFC 3339 format.
-
UnmarshalText
Receiver for *Time v1.0([data])
UnmarshalText implements the encoding.TextUnmarshaler interface.
The time is expected to be in RFC 3339 format.
-
*Timer
Concrete Type v1.0The Timer type represents a single event.
When the Timer expires, the current time will be sent on C,
unless the Timer was created by AfterFunc.
A Timer must be created with NewTimer or AfterFunc.
-
Reset
Receiver for *Timer v1.0([d])
Reset changes the timer to expire after duration d.
It returns true if the timer had been active, false if the timer had
expired or been stopped.
For a Timer created with NewTimer, Reset should be invoked only on
stopped or expired timers with drained channels.
If a program has already received a value from t.C, the timer is known
to have expired and the channel drained, so t.Reset can be used directly.
If a program has not yet received a value from t.C, however,
the timer must be stopped and—if Stop reports that the timer expired
before being stopped—the channel explicitly drained:
if !t.Stop() {
<-t.C
}
t.Reset(d)
This should not be done concurrent to other receives from the Timer's
channel.
Note that it is not possible to use Reset's return value correctly, as there
is a race condition between draining the channel and the new timer expiring.
Reset should always be invoked on stopped or expired channels, as described above.
The return value exists to preserve compatibility with existing programs.
For a Timer created with AfterFunc(d, f), Reset either reschedules
when f will run, in which case Reset returns true, or schedules f
to run again, in which case it returns false.
When Reset returns false, Reset neither waits for the prior f to
complete before returning nor does it guarantee that the subsequent
goroutine running f does not run concurrently with the prior
one. If the caller needs to know whether the prior execution of
f is completed, it must coordinate with f explicitly.
-
Stop
Receiver for *Timer v1.0([])
Stop prevents the Timer from firing.
It returns true if the call stops the timer, false if the timer has already
expired or been stopped.
Stop does not close the channel, to prevent a read from the channel succeeding
incorrectly.
To ensure the channel is empty after a call to Stop, check the
return value and drain the channel.
For example, assuming the program has not received from t.C already:
if !t.Stop() {
<-t.C
}
This cannot be done concurrent to other receives from the Timer's
channel or other calls to the Timer's Stop method.
For a timer created with AfterFunc(d, f), if t.Stop returns false, then the timer
has already expired and the function f has been started in its own goroutine;
Stop does not wait for f to complete before returning.
If the caller needs to know whether f is completed, it must coordinate
with f explicitly.
-
*Weekday
Concrete Type v1.0A Weekday specifies a day of the week (Sunday = 0, ...).
-
Duration
Concrete Type v1.0A Duration represents the elapsed time between two instants
as an int64 nanosecond count. The representation limits the
largest representable duration to approximately 290 years.
-
Hours
Receiver for Duration v1.0([])
Hours returns the duration as a floating point number of hours.
-
Microseconds
Receiver for Duration v1.0([])
Microseconds returns the duration as an integer microsecond count.
-
Milliseconds
Receiver for Duration v1.0([])
Milliseconds returns the duration as an integer millisecond count.
-
Minutes
Receiver for Duration v1.0([])
Minutes returns the duration as a floating point number of minutes.
-
Nanoseconds
Receiver for Duration v1.0([])
Nanoseconds returns the duration as an integer nanosecond count.
-
Round
Receiver for Duration v1.0([m])
Round returns the result of rounding d to the nearest multiple of m.
The rounding behavior for halfway values is to round away from zero.
If the result exceeds the maximum (or minimum)
value that can be stored in a Duration,
Round returns the maximum (or minimum) duration.
If m <= 0, Round returns d unchanged.
-
Seconds
Receiver for Duration v1.0([])
Seconds returns the duration as a floating point number of seconds.
-
String
Receiver for Duration v1.0([])
String returns a string representing the duration in the form "72h3m0.5s".
Leading zero units are omitted. As a special case, durations less than one
second format use a smaller unit (milli-, micro-, or nanoseconds) to ensure
that the leading digit is non-zero. The zero duration formats as 0s.
-
Truncate
Receiver for Duration v1.0([m])
Truncate returns the result of rounding d toward zero to a multiple of m.
If m <= 0, Truncate returns d unchanged.
-
Location
Concrete Type v1.0A Location maps time instants to the zone in use at that time.
Typically, the Location represents the collection of time offsets
in use in a geographical area. For many Locations the time offset varies
depending on whether daylight savings time is in use at the time instant.
-
Month
Concrete Type v1.0A Month specifies a month of the year (January = 1, ...).
-
String
Receiver for Month v1.0([])
String returns the English name of the month ("January", "February", ...).
-
ParseError
Concrete Type v1.0ParseError describes a problem parsing a time string.
-
Ticker
Concrete Type v1.0A Ticker holds a channel that delivers ``ticks'' of a clock
at intervals.
-
Time
Concrete Type v1.0A Time represents an instant in time with nanosecond precision.
Programs using times should typically store and pass them as values,
not pointers. That is, time variables and struct fields should be of
type time.Time, not *time.Time.
A Time value can be used by multiple goroutines simultaneously except
that the methods GobDecode, UnmarshalBinary, UnmarshalJSON and
UnmarshalText are not concurrency-safe.
Time instants can be compared using the Before, After, and Equal methods.
The Sub method subtracts two instants, producing a Duration.
The Add method adds a Time and a Duration, producing a Time.
The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC.
As this time is unlikely to come up in practice, the IsZero method gives
a simple way of detecting a time that has not been initialized explicitly.
Each Time has associated with it a Location, consulted when computing the
presentation form of the time, such as in the Format, Hour, and Year methods.
The methods Local, UTC, and In return a Time with a specific location.
Changing the location in this way changes only the presentation; it does not
change the instant in time being denoted and therefore does not affect the
computations described in earlier paragraphs.
Representations of a Time value saved by the GobEncode, MarshalBinary,
MarshalJSON, and MarshalText methods store the Time.Location's offset, but not
the location name. They therefore lose information about Daylight Saving Time.
In addition to the required “wall clock” reading, a Time may contain an optional
reading of the current process's monotonic clock, to provide additional precision
for comparison or subtraction.
See the “Monotonic Clocks” section in the package documentation for details.
Note that the Go == operator compares not just the time instant but also the
Location and the monotonic clock reading. Therefore, Time values should not
be used as map or database keys without first guaranteeing that the
identical Location has been set for all values, which can be achieved
through use of the UTC or Local method, and that the monotonic clock reading
has been stripped by setting t = t.Round(0). In general, prefer t.Equal(u)
to t == u, since t.Equal uses the most accurate comparison available and
correctly handles the case when only one of its arguments has a monotonic
clock reading.
-
Add
Receiver for Time v1.0([d])
Add returns the time t+d.
-
AddDate
Receiver for Time v1.0([years months days])
AddDate returns the time corresponding to adding the
given number of years, months, and days to t.
For example, AddDate(-1, 2, 3) applied to January 1, 2011
returns March 4, 2010.
AddDate normalizes its result in the same way that Date does,
so, for example, adding one month to October 31 yields
December 1, the normalized form for November 31.
-
After
Receiver for Time v1.0([u])
After reports whether the time instant t is after u.
-
AppendFormat
Receiver for Time v1.0([b layout])
AppendFormat is like Format but appends the textual
representation to b and returns the extended buffer.
-
Before
Receiver for Time v1.0([u])
Before reports whether the time instant t is before u.
-
Clock
Receiver for Time v1.0([])
Clock returns the hour, minute, and second within the day specified by t.
-
Date
Receiver for Time v1.0([])
Date returns the year, month, and day in which t occurs.
-
Day
Receiver for Time v1.0([])
Day returns the day of the month specified by t.
-
Equal
Receiver for Time v1.0([u])
Equal reports whether t and u represent the same time instant.
Two times can be equal even if they are in different locations.
For example, 6:00 +0200 and 4:00 UTC are Equal.
See the documentation on the Time type for the pitfalls of using == with
Time values; most code should use Equal instead.
-
Format
Receiver for Time v1.0([layout])
Format returns a textual representation of the time value formatted according
to the layout defined by the argument. See the documentation for the
constant called Layout to see how to represent the layout format.
The executable example for Time.Format demonstrates the working
of the layout string in detail and is a good reference.
-
GoString
Receiver for Time v1.0([])
GoString implements fmt.GoStringer and formats t to be printed in Go source
code.
-
GobEncode
Receiver for Time v1.0([])
GobEncode implements the gob.GobEncoder interface.
-
Hour
Receiver for Time v1.0([])
Hour returns the hour within the day specified by t, in the range [0, 23].
-
ISOWeek
Receiver for Time v1.0([])
ISOWeek returns the ISO 8601 year and week number in which t occurs.
Week ranges from 1 to 53. Jan 01 to Jan 03 of year n might belong to
week 52 or 53 of year n-1, and Dec 29 to Dec 31 might belong to week 1
of year n+1.
-
In
Receiver for Time v1.0([loc])
In returns a copy of t representing the same time instant, but
with the copy's location information set to loc for display
purposes.
In panics if loc is nil.
-
IsDST
Receiver for Time v1.0([])
IsDST reports whether the time in the configured location is in Daylight Savings Time.
-
IsZero
Receiver for Time v1.0([])
IsZero reports whether t represents the zero time instant,
January 1, year 1, 00:00:00 UTC.
-
Local
Receiver for Time v1.0([])
Local returns t with the location set to local time.
-
Location
Receiver for Time v1.0([])
Location returns the time zone information associated with t.
-
MarshalBinary
Receiver for Time v1.0([])
MarshalBinary implements the encoding.BinaryMarshaler interface.
-
MarshalJSON
Receiver for Time v1.0([])
MarshalJSON implements the json.Marshaler interface.
The time is a quoted string in RFC 3339 format, with sub-second precision added if present.
-
MarshalText
Receiver for Time v1.0([])
MarshalText implements the encoding.TextMarshaler interface.
The time is formatted in RFC 3339 format, with sub-second precision added if present.
-
Minute
Receiver for Time v1.0([])
Minute returns the minute offset within the hour specified by t, in the range [0, 59].
-
Month
Receiver for Time v1.0([])
Month returns the month of the year specified by t.
-
Nanosecond
Receiver for Time v1.0([])
Nanosecond returns the nanosecond offset within the second specified by t,
in the range [0, 999999999].
-
Round
Receiver for Time v1.0([d])
Round returns the result of rounding t to the nearest multiple of d (since the zero time).
The rounding behavior for halfway values is to round up.
If d <= 0, Round returns t stripped of any monotonic clock reading but otherwise unchanged.
Round operates on the time as an absolute duration since the
zero time; it does not operate on the presentation form of the
time. Thus, Round(Hour) may return a time with a non-zero
minute, depending on the time's Location.
-
Second
Receiver for Time v1.0([])
Second returns the second offset within the minute specified by t, in the range [0, 59].
-
String
Receiver for Time v1.0([])
String returns the time formatted using the format string
"2006-01-02 15:04:05.999999999 -0700 MST"
If the time has a monotonic clock reading, the returned string
includes a final field "m=±<value>", where value is the monotonic
clock reading formatted as a decimal number of seconds.
The returned string is meant for debugging; for a stable serialized
representation, use t.MarshalText, t.MarshalBinary, or t.Format
with an explicit format string.
-
Sub
Receiver for Time v1.0([u])
Sub returns the duration t-u. If the result exceeds the maximum (or minimum)
value that can be stored in a Duration, the maximum (or minimum) duration
will be returned.
To compute t-d for a duration d, use t.Add(-d).
-
Truncate
Receiver for Time v1.0([d])
Truncate returns the result of rounding t down to a multiple of d (since the zero time).
If d <= 0, Truncate returns t stripped of any monotonic clock reading but otherwise unchanged.
Truncate operates on the time as an absolute duration since the
zero time; it does not operate on the presentation form of the
time. Thus, Truncate(Hour) may return a time with a non-zero
minute, depending on the time's Location.
-
UTC
Receiver for Time v1.0([])
UTC returns t with the location set to UTC.
-
Unix
Receiver for Time v1.0([])
Unix returns t as a Unix time, the number of seconds elapsed
since January 1, 1970 UTC. The result does not depend on the
location associated with t.
Unix-like operating systems often record time as a 32-bit
count of seconds, but since the method here returns a 64-bit
value it is valid for billions of years into the past or future.
-
UnixMicro
Receiver for Time v1.0([])
UnixMicro returns t as a Unix time, the number of microseconds elapsed since
January 1, 1970 UTC. The result is undefined if the Unix time in
microseconds cannot be represented by an int64 (a date before year -290307 or
after year 294246). The result does not depend on the location associated
with t.
-
UnixMilli
Receiver for Time v1.0([])
UnixMilli returns t as a Unix time, the number of milliseconds elapsed since
January 1, 1970 UTC. The result is undefined if the Unix time in
milliseconds cannot be represented by an int64 (a date more than 292 million
years before or after 1970). The result does not depend on the
location associated with t.
-
UnixNano
Receiver for Time v1.0([])
UnixNano returns t as a Unix time, the number of nanoseconds elapsed
since January 1, 1970 UTC. The result is undefined if the Unix time
in nanoseconds cannot be represented by an int64 (a date before the year
1678 or after 2262). Note that this means the result of calling UnixNano
on the zero Time is undefined. The result does not depend on the
location associated with t.
-
Weekday
Receiver for Time v1.0([])
Weekday returns the day of the week specified by t.
-
Year
Receiver for Time v1.0([])
Year returns the year in which t occurs.
-
YearDay
Receiver for Time v1.0([])
YearDay returns the day of the year specified by t, in the range [1,365] for non-leap years,
and [1,366] in leap years.
-
Zone
Receiver for Time v1.0([])
Zone computes the time zone in effect at time t, returning the abbreviated
name of the zone (such as "CET") and its offset in seconds east of UTC.
-
Timer
Concrete Type v1.0The Timer type represents a single event.
When the Timer expires, the current time will be sent on C,
unless the Timer was created by AfterFunc.
A Timer must be created with NewTimer or AfterFunc.
-
Weekday
Concrete Type v1.0A Weekday specifies a day of the week (Sunday = 0, ...).
-
String
Receiver for Weekday v1.0([])
String returns the English name of the day ("Sunday", "Monday", ...).
-
arrayOfDuration
Concrete Type v1.0A Duration represents the elapsed time between two instants
as an int64 nanosecond count. The representation limits the
largest representable duration to approximately 290 years.
-
arrayOfLocation
Concrete Type v1.0A Location maps time instants to the zone in use at that time.
Typically, the Location represents the collection of time offsets
in use in a geographical area. For many Locations the time offset varies
depending on whether daylight savings time is in use at the time instant.
-
arrayOfMonth
Concrete Type v1.0A Month specifies a month of the year (January = 1, ...).
-
arrayOfParseError
Concrete Type v1.0ParseError describes a problem parsing a time string.
-
arrayOfTicker
Concrete Type v1.0A Ticker holds a channel that delivers ``ticks'' of a clock
at intervals.
-
arrayOfTime
Concrete Type v1.0A Time represents an instant in time with nanosecond precision.
Programs using times should typically store and pass them as values,
not pointers. That is, time variables and struct fields should be of
type time.Time, not *time.Time.
A Time value can be used by multiple goroutines simultaneously except
that the methods GobDecode, UnmarshalBinary, UnmarshalJSON and
UnmarshalText are not concurrency-safe.
Time instants can be compared using the Before, After, and Equal methods.
The Sub method subtracts two instants, producing a Duration.
The Add method adds a Time and a Duration, producing a Time.
The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC.
As this time is unlikely to come up in practice, the IsZero method gives
a simple way of detecting a time that has not been initialized explicitly.
Each Time has associated with it a Location, consulted when computing the
presentation form of the time, such as in the Format, Hour, and Year methods.
The methods Local, UTC, and In return a Time with a specific location.
Changing the location in this way changes only the presentation; it does not
change the instant in time being denoted and therefore does not affect the
computations described in earlier paragraphs.
Representations of a Time value saved by the GobEncode, MarshalBinary,
MarshalJSON, and MarshalText methods store the Time.Location's offset, but not
the location name. They therefore lose information about Daylight Saving Time.
In addition to the required “wall clock” reading, a Time may contain an optional
reading of the current process's monotonic clock, to provide additional precision
for comparison or subtraction.
See the “Monotonic Clocks” section in the package documentation for details.
Note that the Go == operator compares not just the time instant but also the
Location and the monotonic clock reading. Therefore, Time values should not
be used as map or database keys without first guaranteeing that the
identical Location has been set for all values, which can be achieved
through use of the UTC or Local method, and that the monotonic clock reading
has been stripped by setting t = t.Round(0). In general, prefer t.Equal(u)
to t == u, since t.Equal uses the most accurate comparison available and
correctly handles the case when only one of its arguments has a monotonic
clock reading.
-
arrayOfTimer
Concrete Type v1.0The Timer type represents a single event.
When the Timer expires, the current time will be sent on C,
unless the Timer was created by AfterFunc.
A Timer must be created with NewTimer or AfterFunc.
-
arrayOfWeekday
Concrete Type v1.0A Weekday specifies a day of the week (Sunday = 0, ...).