// Generated by Lisette bindgen
// Source: time (Go stdlib)
// Go: 1.25.5
// Lisette: 0.1.12
pub enum Duration: int64 {
Hour = 3600000000000,
Microsecond = 1000,
Millisecond = 1000000,
Minute = 60000000000,
Nanosecond = 1,
Second = 1000000000,
}
/// Common 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
pub const Hour: Duration = 3600000000000
/// Common 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
pub const Microsecond: Duration = 1000
/// Common 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
pub const Millisecond: Duration = 1000000
/// Common 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
pub const Minute: Duration = 60000000000
/// Common 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
pub const Nanosecond: Duration = 1
/// Common 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
pub const Second: Duration = 1000000000
pub enum Month: int {
April = 4,
August = 8,
December = 12,
February = 2,
January = 1,
July = 7,
June = 6,
March = 3,
May = 5,
November = 11,
October = 10,
September = 9,
}
pub const April: Month = 4
pub const August: Month = 8
pub const December: Month = 12
pub const February: Month = 2
pub const January: Month = 1
pub const July: Month = 7
pub const June: Month = 6
pub const March: Month = 3
pub const May: Month = 5
pub const November: Month = 11
pub const October: Month = 10
pub const September: Month = 9
pub enum Weekday: int {
Friday = 5,
Monday = 1,
Saturday = 6,
Sunday = 0,
Thursday = 4,
Tuesday = 2,
Wednesday = 3,
}
pub const Friday: Weekday = 5
pub const Monday: Weekday = 1
pub const Saturday: Weekday = 6
pub const Sunday: Weekday = 0
pub const Thursday: Weekday = 4
pub const Tuesday: Weekday = 2
pub const Wednesday: Weekday = 3
/// After waits for the duration to elapse and then sends the current time
/// on the returned channel.
/// It is equivalent to [NewTimer](d).C.
///
/// Before Go 1.23, this documentation warned that the underlying
/// [Timer] would not be recovered by the garbage collector until the
/// timer fired, and that if efficiency was a concern, code should use
/// NewTimer instead and call [Timer.Stop] if the timer is no longer needed.
/// As of Go 1.23, the garbage collector can recover unreferenced,
/// unstopped timers. There is no reason to prefer NewTimer when After will do.
pub fn After(d: Duration) -> Receiver<Time>
pub fn AfterFunc(d: Duration, f: fn() -> ()) -> Ref<Timer>
pub fn Date(
year: int,
month: Month,
day: int,
hour: int,
min: int,
sec: int,
nsec: int,
loc: Ref<Location>,
) -> Time
pub fn FixedZone(name: string, offset: int) -> Ref<Location>
pub fn LoadLocation(name: string) -> Result<Ref<Location>, error>
pub fn LoadLocationFromTZData(name: string, data: Slice<uint8>) -> Result<Ref<Location>, error>
pub fn NewTicker(d: Duration) -> Ref<Ticker>
pub fn NewTimer(d: Duration) -> Ref<Timer>
pub fn Now() -> Time
pub fn Parse(layout: string, value: string) -> Result<Time, error>
pub fn ParseDuration(s: string) -> Result<Duration, error>
pub fn ParseInLocation(layout: string, value: string, loc: Ref<Location>) -> Result<Time, error>
pub fn Since(t: Time) -> Duration
/// Sleep pauses the current goroutine for at least the duration d.
/// A negative or zero duration causes Sleep to return immediately.
pub fn Sleep(d: Duration)
/// Tick is a convenience wrapper for [NewTicker] providing access to the ticking
/// channel only. Unlike NewTicker, Tick will return nil if d <= 0.
///
/// Before Go 1.23, this documentation warned that the underlying
/// [Ticker] would never be recovered by the garbage collector, and that
/// if efficiency was a concern, code should use NewTicker instead and
/// call [Ticker.Stop] when the ticker is no longer needed.
/// As of Go 1.23, the garbage collector can recover unreferenced
/// tickers, even if they haven't been stopped.
/// The Stop method is no longer necessary to help the garbage collector.
/// There is no longer any reason to prefer NewTicker when Tick will do.
pub fn Tick(d: Duration) -> Receiver<Time>
pub fn Unix(sec: int64, nsec: int64) -> Time
pub fn UnixMicro(usec: int64) -> Time
pub fn UnixMilli(msec: int64) -> Time
pub fn Until(t: Time) -> Duration
/// A 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.
///
/// Location is used to provide a time zone in a printed Time value and for
/// calculations involving intervals that may cross daylight savings time
/// boundaries.
pub type Location
/// ParseError describes a problem parsing a time string.
pub struct ParseError {
pub Layout: string,
pub Value: string,
pub LayoutElem: string,
pub ValueElem: string,
pub Message: string,
}
/// A Ticker holds a channel that delivers “ticks” of a clock
/// at intervals.
pub struct Ticker {
pub C: Receiver<Time>,
}
/// A 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 [Time.GobDecode], [Time.UnmarshalBinary], [Time.UnmarshalJSON] and
/// [Time.UnmarshalText] are not concurrency-safe.
///
/// Time instants can be compared using the [Time.Before], [Time.After], and [Time.Equal] methods.
/// The [Time.Sub] method subtracts two instants, producing a [Duration].
/// The [Time.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 [Time.IsZero] method gives
/// a simple way of detecting a time that has not been initialized explicitly.
///
/// Each time has an associated [Location]. The methods [Time.Local], [Time.UTC], and Time.In return a
/// Time with a specific Location. Changing the Location of a Time value with
/// these methods does not change the actual instant it represents, only the time
/// zone in which to interpret it.
///
/// Representations of a Time value saved by the [Time.GobEncode], [Time.MarshalBinary], [Time.AppendBinary],
/// [Time.MarshalJSON], [Time.MarshalText] and [Time.AppendText] 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.
pub type Time
/// The 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.
pub struct Timer {
pub C: Receiver<Time>,
}
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const ANSIC = "Mon Jan _2 15:04:05 2006"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const DateOnly = "2006-01-02"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const DateTime = "2006-01-02 15:04:05"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const Kitchen = "3:04PM"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const Layout = "01/02 03:04:05PM '06 -0700"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RFC1123 = "Mon, 02 Jan 2006 15:04:05 MST"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RFC1123Z = "Mon, 02 Jan 2006 15:04:05 -0700"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RFC3339 = "2006-01-02T15:04:05Z07:00"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RFC822 = "02 Jan 06 15:04 MST"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RFC822Z = "02 Jan 06 15:04 -0700"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RFC850 = "Monday, 02-Jan-06 15:04:05 MST"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const RubyDate = "Mon Jan 02 15:04:05 -0700 2006"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const Stamp = "Jan _2 15:04:05"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const StampMicro = "Jan _2 15:04:05.000000"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const StampMilli = "Jan _2 15:04:05.000"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const StampNano = "Jan _2 15:04:05.000000000"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const TimeOnly = "15:04:05"
/// These 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.
/// When using the [RFC1123] or [RFC1123Z] formats for parsing, note that these
/// formats define a leading zero for the day-in-month portion, which is not
/// strictly allowed by RFC 1123. This will result in an error when parsing
/// date strings that occur in the first 9 days of a given month.
/// 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" "01" "1"
/// Day of the week: "Mon" "Monday"
/// Day of the month: "2" "_2" "02"
/// 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
/// "-070000" ±hhmmss
/// "-07:00:00" ±hh:mm:ss
///
/// 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
/// "Z070000" Z or ±hhmmss
/// "Z07:00:00" Z or ±hh:mm:ss
///
/// 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.
const UnixDate = "Mon Jan _2 15:04:05 MST 2006"
pub var Local: Ref<Location>
pub var UTC: Ref<Location>
impl Duration {
/// Abs returns the absolute value of d.
/// As a special case, Duration([math.MinInt64]) is converted to Duration([math.MaxInt64]),
/// reducing its magnitude by 1 nanosecond.
fn Abs(self) -> Duration
/// Hours returns the duration as a floating point number of hours.
fn Hours(self) -> float64
/// Microseconds returns the duration as an integer microsecond count.
fn Microseconds(self) -> int64
/// Milliseconds returns the duration as an integer millisecond count.
fn Milliseconds(self) -> int64
/// Minutes returns the duration as a floating point number of minutes.
fn Minutes(self) -> float64
/// Nanoseconds returns the duration as an integer nanosecond count.
fn Nanoseconds(self) -> int64
/// 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.
fn Round(self, m: Duration) -> Duration
/// Seconds returns the duration as a floating point number of seconds.
fn Seconds(self) -> float64
/// 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.
fn String(self) -> string
/// Truncate returns the result of rounding d toward zero to a multiple of m.
/// If m <= 0, Truncate returns d unchanged.
fn Truncate(self, m: Duration) -> Duration
}
impl Location {
/// String returns a descriptive name for the time zone information,
/// corresponding to the name argument to [LoadLocation] or [FixedZone].
fn String(self: Ref<Location>) -> string
}
impl Month {
/// String returns the English name of the month ("January", "February", ...).
fn String(self) -> string
}
impl ParseError {
/// Error returns the string representation of a ParseError.
fn Error(self: Ref<ParseError>) -> string
}
impl Ticker {
/// 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.
fn Reset(self: Ref<Ticker>, d: Duration)
/// 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".
fn Stop(self: Ref<Ticker>)
}
impl Time {
/// Add returns the time t+d.
fn Add(self, d: Duration) -> Time
/// 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.
///
/// Note that dates are fundamentally coupled to timezones, and calendrical
/// periods like days don't have fixed durations. AddDate uses the Location of
/// the Time value to determine these durations. That means that the same
/// AddDate arguments can produce a different shift in absolute time depending on
/// the base Time value and its Location. For example, AddDate(0, 0, 1) applied
/// to 12:00 on March 27 always returns 12:00 on March 28. At some locations and
/// in some years this is a 24 hour shift. In others it's a 23 hour shift due to
/// daylight savings time transitions.
///
/// 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.
fn AddDate(self, years: int, months: int, days: int) -> Time
/// After reports whether the time instant t is after u.
fn After(self, u: Time) -> bool
/// AppendBinary implements the [encoding.BinaryAppender] interface.
fn AppendBinary(self, mut b: Slice<uint8>) -> Result<Slice<uint8>, error>
/// AppendFormat is like [Time.Format] but appends the textual
/// representation to b and returns the extended buffer.
fn AppendFormat(self, mut b: Slice<uint8>, layout: string) -> Slice<uint8>
/// AppendText implements the [encoding.TextAppender] interface.
/// The time is formatted in RFC 3339 format with sub-second precision.
/// If the timestamp cannot be represented as valid RFC 3339
/// (e.g., the year is out of range), then an error is returned.
fn AppendText(self, mut b: Slice<uint8>) -> Result<Slice<uint8>, error>
/// Before reports whether the time instant t is before u.
fn Before(self, u: Time) -> bool
/// Clock returns the hour, minute, and second within the day specified by t.
fn Clock(self) -> (int, int, int)
/// Compare compares the time instant t with u. If t is before u, it returns -1;
/// if t is after u, it returns +1; if they're the same, it returns 0.
fn Compare(self, u: Time) -> int
/// Date returns the year, month, and day in which t occurs.
fn Date(self) -> (int, Month, int)
/// Day returns the day of the month specified by t.
fn Day(self) -> int
/// 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.
fn Equal(self, u: Time) -> bool
/// 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.
fn Format(self, layout: string) -> string
/// GoString implements [fmt.GoStringer] and formats t to be printed in Go source
/// code.
fn GoString(self) -> string
/// GobDecode implements the gob.GobDecoder interface.
fn GobDecode(self: Ref<Time>, data: Slice<uint8>) -> Result<(), error>
/// GobEncode implements the gob.GobEncoder interface.
fn GobEncode(self) -> Result<Slice<uint8>, error>
/// Hour returns the hour within the day specified by t, in the range [0, 23].
fn Hour(self) -> int
/// 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.
fn ISOWeek(self) -> (int, int)
/// 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.
fn In(self, loc: Ref<Location>) -> Time
/// IsDST reports whether the time in the configured location is in Daylight Savings Time.
fn IsDST(self) -> bool
/// IsZero reports whether t represents the zero time instant,
/// January 1, year 1, 00:00:00 UTC.
fn IsZero(self) -> bool
/// Local returns t with the location set to local time.
fn Local(self) -> Time
/// Location returns the time zone information associated with t.
fn Location(self) -> Ref<Location>
/// MarshalBinary implements the [encoding.BinaryMarshaler] interface.
fn MarshalBinary(self) -> Result<Slice<uint8>, error>
/// MarshalJSON implements the [encoding/json.Marshaler] interface.
/// The time is a quoted string in the RFC 3339 format with sub-second precision.
/// If the timestamp cannot be represented as valid RFC 3339
/// (e.g., the year is out of range), then an error is reported.
fn MarshalJSON(self) -> Result<Slice<uint8>, error>
/// MarshalText implements the [encoding.TextMarshaler] interface. The output
/// matches that of calling the [Time.AppendText] method.
///
/// See [Time.AppendText] for more information.
fn MarshalText(self) -> Result<Slice<uint8>, error>
/// Minute returns the minute offset within the hour specified by t, in the range [0, 59].
fn Minute(self) -> int
/// Month returns the month of the year specified by t.
fn Month(self) -> Month
/// Nanosecond returns the nanosecond offset within the second specified by t,
/// in the range [0, 999999999].
fn Nanosecond(self) -> int
/// 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.
fn Round(self, d: Duration) -> Time
/// Second returns the second offset within the minute specified by t, in the range [0, 59].
fn Second(self) -> int
/// 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.
fn String(self) -> string
/// 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).
fn Sub(self, u: Time) -> Duration
/// 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.
fn Truncate(self, d: Duration) -> Time
/// UTC returns t with the location set to UTC.
fn UTC(self) -> Time
/// 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.
fn Unix(self) -> int64
/// 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.
fn UnixMicro(self) -> int64
/// 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.
fn UnixMilli(self) -> int64
/// 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.
fn UnixNano(self) -> int64
/// UnmarshalBinary implements the [encoding.BinaryUnmarshaler] interface.
fn UnmarshalBinary(self: Ref<Time>, data: Slice<uint8>) -> Result<(), error>
/// UnmarshalJSON implements the [encoding/json.Unmarshaler] interface.
/// The time must be a quoted string in the RFC 3339 format.
fn UnmarshalJSON(self: Ref<Time>, data: Slice<uint8>) -> Result<(), error>
/// UnmarshalText implements the [encoding.TextUnmarshaler] interface.
/// The time must be in the RFC 3339 format.
fn UnmarshalText(self: Ref<Time>, data: Slice<uint8>) -> Result<(), error>
/// Weekday returns the day of the week specified by t.
fn Weekday(self) -> Weekday
/// Year returns the year in which t occurs.
fn Year(self) -> int
/// 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.
fn YearDay(self) -> int
/// 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.
fn Zone(self) -> (string, int)
/// ZoneBounds returns the bounds of the time zone in effect at time t.
/// The zone begins at start and the next zone begins at end.
/// If the zone begins at the beginning of time, start will be returned as a zero Time.
/// If the zone goes on forever, end will be returned as a zero Time.
/// The Location of the returned times will be the same as t.
fn ZoneBounds(self) -> (Time, Time)
}
impl Timer {
/// 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 func-based 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.
///
/// For a chan-based timer created with NewTimer, as of Go 1.23,
/// any receive from t.C after Reset has returned is guaranteed not
/// to receive a time value corresponding to the previous timer settings;
/// if the program has not received from t.C already and the timer is
/// running, Reset is guaranteed to return true.
/// Before Go 1.23, the only safe way to use Reset was to call [Timer.Stop]
/// and explicitly drain the timer first.
/// See the [NewTimer] documentation for more details.
fn Reset(self: Ref<Timer>, d: Duration) -> bool
/// 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.
///
/// For a func-based 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.
///
/// For a chan-based timer created with NewTimer(d), as of Go 1.23,
/// any receive from t.C after Stop has returned is guaranteed to block
/// rather than receive a stale time value from before the Stop;
/// if the program has not received from t.C already and the timer is
/// running, Stop is guaranteed to return true.
/// Before Go 1.23, the only safe way to use Stop was insert an extra
/// <-t.C if Stop returned false to drain a potential stale value.
/// See the [NewTimer] documentation for more details.
fn Stop(self: Ref<Timer>) -> bool
}
impl Weekday {
/// String returns the English name of the day ("Sunday", "Monday", ...).
fn String(self) -> string
}