Announcing Go-TinyTime, Go-TinyDate’s Sister Package
Tags: education, showdev, go, opensource
Published: 2020-04-02 12:38:57

---
title: Announcing Go-TinyTime, Go-TinyDate’s Sister Package
published: true
date: 2020-04-02 12:37:11 UTC
tags: education,showdev,golang,open-source
canonical_url: https://qvault.io/2020/04/02/announcing-go-tinytime-go-tinydates-sister-package/
---

![](https://i0.wp.com/qvault.io/wp-content/uploads/2020/04/tinyclock.jpeg?resize=382%2C253&ssl=1)

[time.Time](https://golang.org/pkg/time/#Time) is the perfect choice for most cases, it even comes in the standard library! The problem is that the time.Time{} struct uses more than **24 bytes** of memory under most conditions. [Go-TinyTime](https://github.com/lane-c-wagner/go-tinytime) solves this problem by restricting the available dates to the range between 1970 – 2106, and only supporting UTC timezones. This brings data usage down to just **4 bytes** of memory.

Go-TinyDate is its sister package that allows for a much larger date range but doesn’t get more than **day** precision. Between **time.Time** , **go-tinydate** , and **go-tinytime** all of our time problems can be solved using the same API.

Don’t forget to ![⭐](https://s.w.org/images/core/emoji/12.0.0-1/72x72/2b50.png)the GitHub: [https://github.com/lane-c-wagner/go-tinytime](https://github.com/lane-c-wagner/go-tinytime)

## How Does It Work?

A normal time.Time object takes at least 16 bytes of memory:

```
type Time struct {
	wall uint64 // 8 bytes
	ext int64 // b bytes
	loc *Location // 8 bytes if not nil, plus location memory
}
```

If there is a location set (which there usually is), then this can be higher, usually about 24 bytes.

TinyTime, on the other hand, uses on 4 bytes.

```
type TinyTime struct {
	unix uint32
}
```

We sacrifice timezones and dates older than the unix epoch of 1970, but if these are acceptable tradeoffs, we can save a lot of memory.

## When Should It Be Used?

As the TinyTime [Readme](https://github.com/lane-c-wagner/go-tinytime/blob/master/README.md) states, if you aren’t hurting for resources, better to stick with the standard time.Time. The following situations can be good reasons to use to TinyTime:

- You are working in embedded systems and every byte counts
- You are working on a system that stores thousands of dates, and reducing memory costs by >75% is significant
- You are sure you will never need more than date precision

## API

The tinytime.TinyTime API largely mirrors that of time.Time. The only methods missing are the ones that make no sense without timezone support. The vast majority can be swapped out without any changes. Check out the godoc for reference: [https://godoc.org/github.com/lane-c-wagner/go-tinytime](https://godoc.org/github.com/lane-c-wagner/go-tinytime).

## TinyDate

If you need a larger date range, be sure to check out the intro to Go-TinyDate:

[https://qvault.io/2020/03/23/i-wrote-go-tinydate-the-missing-golang-date-package/](https://qvault.io/2020/03/23/i-wrote-go-tinydate-the-missing-golang-date-package/)

![](https://i0.wp.com/qvault.io/wp-content/uploads/2020/03/package.jpeg?resize=491%2C327&ssl=1)

## Thanks For Reading

Hit me up on twitter [@wagslane](https://twitter.com/wagslane) if you have any questions or comments.

Follow me on Dev.to: [wagslane](https://dev.to/wagslane)

The post [Announcing Go-TinyTime, Go-TinyDate’s Sister Package](https://qvault.io/2020/04/02/announcing-go-tinytime-go-tinydates-sister-package/) appeared first on [Qvault](https://qvault.io).