Timezone

Package epochdate provides date handling in a compact format. Represents dates from Jan 1 1970 - Jun 6 2149 as days since the Unix epoch. This format requires 2 bytes (it's a uint16), in contrast to the 16 or 20 byte representations (on 32 or 64-bit systems, respectively) used by the standard time package. Timezone is accounted for when applicable; when converting from standard time format into a Date, the date relative to the time value's zone is retained. Times at any point during a given day (relative to timezone) are normalized to the same date. Conversely, conversions back to standard time format may be done using the Local, UTC, and In methods (semantically corresponding to the same-named Time methods), but with the result normalized to midnight (the beginning of the day) relative to that timezone. All functions and methods with the same names as those found in the stdlib time package have identical semantics in epochdate, with the exception that epochdate truncates time-of-day information.

Package tz contains timezone lists.

Package teq is a Go library designed to enhance your testing experience by providing a flexible and customizable way to perform deep equality checks. It's especially useful when you need to compare complex objects or types that have specific equality conditions. - Transforms: Register a "transform" function that can modify objects before comparison. This allows you to control how equality is determined. For example, by transforming time.Time objects to UTC, you can make your equality checks timezone-insensitive. - Formats: Register a "format" function that defines how objects are displayed when they are not equal. This is useful for types like time.Time and decimal.Decimal that may not be human-readable in their default format. By registering your own format, you can make the output of your tests more understandable. To use teq, you first need to create a new instance: Then, you can add your transforms and formats: Finally, you can use teq to perform deep equality checks in your tests:

Package alog is an implementation of a fully concurrent non-IO blocking log library. Internally messages are routed through a number of subscribed destinations consisting of destination log levels, timezone formatting strings and an io.Writer for the destination to be written to. The globally available functions utilize a singleton implementation of a global logger that is initialized when the package is loaded. This global logger utilizes os.Stdout for INFO, DEBUG, TRACE, WARN, CUSTOM logs, and os.Stderr for ERROR, CRITICAL, FATAL as defined in the method Standard() The global logger singleton can be overridden using the "Global" method passing in the proper parameters as required by your use case. If you prefer to use a non-global singleton logger you can use the "New" method to create a new logger which implements the alog packages "Logger" interface which can be passed throughout an application as a logger. Each log level has an associated function: c(channel) functions are special methods in the logger that rather than being called directly are passed a channel which receives logs into the logger in a concurrent manner without direct calls to the `c(channel) function` again afterwards. These methods are particularly useful for applications where the overhead of a logger in concurrent actions is a particular nuisance. For these cases the c(channel) functions are a perfect use case. Each log level supports it's own c(channel) function. alog currently support two log formatting types * STD => Formats your logs using a "PREFIX DATE [LEVEL] Log | err: Error" * JSON => Formats your logs using JSON in the following form `{"prefix":"PREFIX","type":"ERROR","timestamp":"2020-03-01T16:21:28-06:00","error":"ERROR","messages":["ERROR"]}`

Represents dates from Jan 1 1970 - Jun 6 2149 as days since the Unix epoch. This format requires 2 bytes (it's a uint16), in contrast to the 16 or 20 byte representations (on 32 or 64-bit systems, respectively) used by the standard time package. Timezone is accounted for when applicable; when converting from standard time format into a Date, the date relative to the time value's zone is retained. Times at any point during a given day (relative to timezone) are normalized to the same date. Conversely, conversions back to standard time format may be done using the Local, UTC, and In methods (semantically corresponding to the same-named Time methods), but with the result normalized to midnight (the beginning of the day) relative to that timezone. All functions and methods with the same names as those found in the stdlib time package have identical semantics in epochdate, with the exception that epochdate truncates time-of-day information.

Package alog is an implementation of a fully concurrent non-IO blocking log library. Internally messages are routed through a number of subscribed destinations consisting of destination log levels, timezone formatting strings and an io.Writer for the destination to be written to. The globally available functions utilize a singleton implementation of a global logger that is initialized when the package is loaded. This global logger utilizes os.Stdout for INFO, DEBUG, TRACE, WARN, CUSTOM logs, and os.Stderr for ERROR, CRITICAL, FATAL as defined in the method Standard() The global logger singleton can be overridden using the "Global" method passing in the proper parameters as required by your use case. If you prefer to use a non-global singleton logger you can use the "New" method to create a new logger which implements the alog packages "Logger" interface which can be passed throughout an application as a logger. Each log level has an associated function: c(channel) functions are special methods in the logger that rather than being called directly are passed a channel which receives logs into the logger in a concurrent manner without direct calls to the `c(channel) function` again afterwards. These methods are particularly useful for applications where the overhead of a logger in concurrent actions is a particular nuisance. For these cases the c(channel) functions are a perfect use case. Each log level supports it's own c(channel) function. alog currently support two log formatting types * STD => Formats your logs using a "PREFIX DATE [LEVEL] Log | err: Error" * JSON => Formats your logs using JSON in the following form `{"prefix":"PREFIX","type":"ERROR","timestamp":"2020-03-01T16:21:28-06:00","error":"ERROR","messages":["ERROR"]}`

Package latlong maps from a latitude and longitude to a timezone. It uses the data from http://efele.net/maps/tz/world/ compressed down to an internal form optimized for low memory overhead and fast lookups at the expense of perfect accuracy when close to borders. The data files are compiled in to this package and do not require explicit loading.

Package rtz maps from a latitude and longitude to a timezone of Russian Federation. It is based on data provided by github.com/bradfitz/latlong package (forked and patched).

Package tzf is a package convert (lng,lat) to timezone. Inspired by timezonefinder https://github.com/jannikmi/timezonefinder, fast python package for finding the timezone of any point on earth (coordinates) offline.

Package alog is an implementation of a fully concurrent non-IO blocking log library. Internally messages are routed through a number of subscribed destinations consisting of destination log levels, timezone formatting strings and an io.Writer for the destination to be written to. The globaly available functions utilize a singleton implementation of a global logger that is initialized when the package is loaded. This global logger utilizes os.Stdout for INFO, DEBUG, TRACE, WARN, CUSTOM logs, and os.Stderr for ERROR, CRITICAL, FATAL as defined in the method Standard() The global logger singleton can be overridden using the "Global" method passing in the proper parameters as required by your use case. If you prefer to use a non-global singleton logger you can use the "New" method to create a new logger which implements the alog packages "Logger" interface which can be passed throughout an application as a logger. Each log level has an associated function: * Print, Printf, Println, Printc => INFO * Debug, Debugf, Debugln, Debugc => DEBUG * Trace, Tracef, Traceln, Tracec => TRACE * Warn, Warnf, Warnln, Warnc => WARN * Error, Errorf, Errorln, Errorc => ERROR * Crit, Critf, Critln, Critc => CRITICAL * Fatal, Fatalf, Fatalln, Fatalc => FATAL * Custom, Customf, Customln, Customc => CUSTOM Level c(channel) functions are special methods in the logger that rather than being called directly are passed a channel which receives logs into the logger in a concurrent manner without direct calls to the `c(channel) function` again afterwards. These methods are particularly useful for applications where the overhead of a logger in concurrent actions is a particular nuisance. For these cases the c(channel) functions are a perfect use case. Each log level supports it's own c(channel) function. alog currently support two log formatting types * STD => Formats your logs using a "PREFIX DATE [LEVEL] Log | err: Error" * JSON => Formats your logs using JSON in the following form `{"prefix":"PREFIX","type":"ERROR","timestamp":"2020-03-01T16:21:28-06:00","error":"ERROR","messages":["ERROR"]}`

Package latlong maps from a latitude and longitude to a timezone. It uses the data from http://efele.net/maps/tz/world/ compressed down to an internal form optimized for low memory overhead and fast lookups at the expense of perfect accuracy when close to borders. The data files are compiled in to this package and do not require explicit loading.

Package latlong maps from a latitude and longitude to a timezone. It uses the data from http://efele.net/maps/tz/world/ compressed down to an internal form optimized for low memory overhead and fast lookups at the expense of perfect accuracy when close to borders. The data files are compiled in to this package and do not require explicit loading.

Package civil provides types for representing civil dates, and times. Sometimes it is useful to be able to represent a date or time without reference to an instance in time within a timezone. For example, when recording a person's date of birth all that is needed is a date. There is no requirement to specify an instant in time within a timezone. There are also circumstances where an event will be scheduled for a date and time in the local timezone, whatever that may be. And example of this might be a schedule for taking medication.

Package windowsiana provides support in converting date timezones from the non-standard windows timezone format into UTC. It also provides a function to return a timezone-aware date given a date string and an IANA timezone the date can then be used as a UTC date via the .UTC() function

Represents dates from Jan 1 1970 - Jun 6 2149 as days since the Unix epoch. This format requires 2 bytes (it's a uint16), in contrast to the 16 or 20 byte representations (on 32 or 64-bit systems, respectively) used by the standard time package. Timezone is accounted for when applicable; when converting from standard time format into a Date, the date relative to the time value's zone is retained. Times at any point during a given day (relative to timezone) are normalized to the same date. Conversely, conversions back to standard time format may be done using the Local, UTC, and In methods (semantically corresponding to the same-named Time methods), but with the result normalized to midnight (the beginning of the day) relative to that timezone. All functions and methods with the same names as those found in the stdlib time package have identical semantics in epochdate, with the exception that epochdate truncates time-of-day information.

Package latlong maps from a latitude and longitude to a timezone. It uses the data from http://efele.net/maps/tz/world/ compressed down to an internal form optimized for low memory overhead and fast lookups at the expense of perfect accuracy when close to borders. The data files are compiled in to this package and do not require explicit loading.

Package latlong maps from a latitude and longitude to a timezone. It uses the data from http://efele.net/maps/tz/world/ compressed down to an internal form optimized for low memory overhead and fast lookups at the expense of perfect accuracy when close to borders. The data files are compiled in to this package and do not require explicit loading.

Package local provides types for representing local dates, times and date-times. Sometimes it is useful to be able to represent a date or time without reference to an instance in time with a timezone. For example, when recording a person's date of birth all that is needed is a date. There is no requirement to specify an instant in time with timezone. Similarly, when scheduling activities to happen such as a meal time, wakeup, bedtime, etc, it is enough to be able to specify the time of day. The date and timezone might not be relevant in the context. Like the standard library time package, the local package uses a Gregorian calendar for all calculations. The local package makes use of the time package for all of its date-time calculations.

Package tz contains time zone info so that you can predictably load Locations regardless of the locations available on the locally running operating system. The stdlib time.LoadLocation function loads timezone data from the operating system or from zoneinfo.zip in a local Go installation. Both of these are often missing from some operating systems, especially Windows. This package has the zoneinfo.zip from Go embedded into the package so that queries to load a location always return the same data regardless of operating system. This package exists because of https://github.com/golang/go/issues/21881.

package clock provides methods for determining the corresponding time in other timezones in the world.

Package epochdate provides date handling in a compact format. Represents dates from Jan 1 1970 - Jun 6 2149 as days since the Unix epoch. This format requires 2 bytes (it's a uint16), in contrast to the 16 or 20 byte representations (on 32 or 64-bit systems, respectively) used by the standard time package. Timezone is accounted for when applicable; when converting from standard time format into a Date, the date relative to the time value's zone is retained. Times at any point during a given day (relative to timezone) are normalized to the same date. Conversely, conversions back to standard time format may be done using the Local, UTC, and In methods (semantically corresponding to the same-named Time methods), but with the result normalized to midnight (the beginning of the day) relative to that timezone. All functions and methods with the same names as those found in the stdlib time package have identical semantics in epochdate, with the exception that epochdate truncates time-of-day information. epochdate does not handle leap seconds, and is thus generally follows the behavior of the standard library time package, which it uses for translating to and from Date and YearMonth values, parsing, and formatting. epochdate does not handle leap seconds, which may result in a low risk of date inconsistencies when calling New/ClampFromUnix directly, if that timestamp falls on the zeroth second of a day more than six months in the future. In particular, if that second was selected as a leap second, the initial call may result in a value one lower than if that same call were made after the leap second had been amended into the standard library time package. Using New/ClampFromTime and New/ClampFromDate should prevent such a discrepancy.

Package latlong maps from a latitude and longitude to a timezone. It uses the data from http://efele.net/maps/tz/world/ compressed down to an internal form optimized for low memory overhead and fast lookups at the expense of perfect accuracy when close to borders. The data files are compiled in to this package and do not require explicit loading.

Package tz provides timezone lookup for a given location * The timezone shapefile is embedded in the build binary using go-bindata * Supports overlapping zones * You can load your own geojson shapefile if you want * Sub millisecond lookup even on old hardware * The shapefile is simplified using a lossy method so it may be innacurate along the borders * This is purerly in-memory. Uses ~50MB of ram

Package alog is an implementation of a fully concurrent non-IO blocking log library. Internally messages are routed through a number of subscribed destinations consisting of destination log levels, timezone formatting strings and an io.Writer for the destination to be written to. The globally available functions utilize a singleton implementation of a global logger that is initialized when the package is loaded. This global logger utilizes os.Stdout for INFO, DEBUG, TRACE, WARN, CUSTOM logs, and os.Stderr for ERROR, CRITICAL, FATAL as defined in the method Standard() The global logger singleton can be overridden using the "Global" method passing in the proper parameters as required by your use case. If you prefer to use a non-global singleton logger you can use the "New" method to create a new logger which implements the alog packages "Logger" interface which can be passed throughout an application as a logger. Each log level has an associated function: c(channel) functions are special methods in the logger that rather than being called directly are passed a channel which receives logs into the logger in a concurrent manner without direct calls to the `c(channel) function` again afterwards. These methods are particularly useful for applications where the overhead of a logger in concurrent actions is a particular nuisance. For these cases the c(channel) functions are a perfect use case. Each log level supports it's own c(channel) function. alog currently support two log formatting types * STD => Formats your logs using a "PREFIX DATE [LEVEL] Log | err: Error" * JSON => Formats your logs using JSON in the following form `{"prefix":"PREFIX","type":"ERROR","timestamp":"2020-03-01T16:21:28-06:00","error":"ERROR","messages":["ERROR"]}`

Package localtimezone provides timezone lookup for a given location * The timezone shapefile is embedded in the build binary using go-bindata * Supports overlapping zones * You can load your own geojson shapefile if you want * Sub millisecond lookup even on old hardware * The shapefile is simplified using a lossy method so it may be innacurate along the borders * This is purely in-memory. Uses ~50MB of ram

===----------- cassandra.go - cassandra interface in go -------------=== ===----------- cql.go - c* utility written in go -------------=== ===----------- fb.go - facebook CAPI interface written in go -------------=== ===----------- nats.go - nats interface written in go -------------=== ===----------- tracker.go - tracking utility written in go -------------=== ===----------- udt.go - udt for cassandra data types -------------=== ===----------- utils.go - tracking utility written in go -------------=== ===----------- zones.go - timezone tracking utility -------------=== * `...

Package gojlogger provides a custom logger with Info, Warning an Error logging methods. The default timezone is UTC, use TimeZoneUTC = false for system timezone. Package usage:

Package timezones builds new time.Locations.

Package latlong maps from a latitude and longitude to a timezone. It uses the data from http://efele.net/maps/tz/world/ compressed down to an internal form optimized for low memory overhead and fast lookups at the expense of perfect accuracy when close to borders. The data files are compiled in to this package and do not require explicit loading.

Package tzloc generate the full list of location enumeration of IANA timezone database. The data source is from Go standard library lib/time/zoneinfo.zip You can also check the list from wikipedia: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones Due to the variable database, the Go team seems not likely to add the enum to the standard library for keeping backward compatibility. You can see the discussion on this issue: https://github.com/golang/go/issues/36278

Package dateformatter helps formatting date in the correct locale. It uses data extracted from CLDR v27.0.1. It has the same formatting options as the time package of the standard library, excluding timezones and nanoseconds as they are not needed in a daily basis to format user-facing dates and times. It has support for the following langs: spanish, english, french and russian. More can be added on demand modifying the generator to create the symbols files.

Package dateformatter helps formatting date in the correct locale. It uses data extracted from CLDR v27.0.1. It has the same formatting options as the time package of the standard library, excluding timezones and nanoseconds as they are not needed in a daily basis to format user-facing dates and times. It has support for the following langs: spanish, english, french and russian. More can be added on demand modifying the generator to create the symbols files.

Package timezone is timezone utility package.