justinmimbs / timezone-data Goto Github PK

View Code? Open in Web Editor NEW

27.0 4.0 5.0 131 KB

An Elm package containing time zone data from the IANA Time Zone Database

Home Page: https://package.elm-lang.org/packages/justinmimbs/timezone-data/latest/

License: BSD 3-Clause "New" or "Revised" License

Python 5.57% Shell 0.22% Elm 94.22%

timezone-data's Introduction

timezone-data

This Elm package contains time zone data from the IANA Time Zone Database for using with elm/time.

The elm/time library provides a Posix type for representing an instant in time. Extracting human-readable parts from a Posix time requires a Time.Zone. This library provides Time.Zone values for all named zones in the database, covering changes between 1970 and 2037.

Installation

elm install justinmimbs/timezone-data

Examples

Get the local time zone

The TimeZone.getZone task gets the client's local Time.Zone along with its zone name.

import Time
import TimeZone

getZone : Task TimeZone.Error ( String, Time.Zone )
getZone =
    TimeZone.getZone

See this page for a full example.

Get a specific time zone

Each zone is stored as a function, waiting to be evaluated to a Time.Zone.

import Time
import TimeZone exposing (america__new_york)


-- unevaluated

lazyZone : () -> Time.Zone
lazyZone =
    america__new_york


-- evaluated

zone : Time.Zone
zone =
    america__new_york ()

Once evaluated, you should store the Time.Zone values you need in your model so that they don't need to be evaluated again.

Alternatives

Using this library to include all time zones in your compiled asset would increase its minified and gzipped size by about 18 KB. For a more lightweight approach to getting time zones into Elm, you may consider fetching only the data you need at runtime. And if your use case is taking UTC timestamps and displaying them nicely formatted in the client's local time, then you may look into custom elements, like Github's time-elements.

timezone-data's People

Contributors

Stargazers

Watchers

Forkers

nazarsh pd9333 janjelinek mackeyrms k-bx

timezone-data's Issues

Wrong daylight savings time "switch" for Oslo timezone

First off, great library!

We currently have a bug where time zone information seems a bit wrong. It seems that times goes away from time light savings on Sunday at 01:00 am. However, in Norway we do this switch at 03:00 am on sunday.

We use this library in a travel planer for trains, so currently people are seeing travel times like "00:04 -> 00:18" when it should be "00:04 -> 01:18"

Add support for deprecated timezones

I was wondering if you were open to adding support for deprecated timezone such as "US/Arizona", "US/***". My reasoning behind this is that T work in the healthcare industry and a lot of hospitals are well behind the times in technology and still use the deprecated timezones. I would also assume that when interfacing with an older server would result in the same sort of incompatibility.

Currently my fix is to just map the old timezone to the new time zone. But it would be better if this package just handled all timezones.

[Feature Request] Add enoder and decoder for Zone type

Right now, it's easy enough to get the Zone from a string using the zones Dict. However, what isn't as easy is encoding the Zone back into a string.

It would be nice to have an encoder that did this. And since there would be an encoder, it would make sense to also have a decoder.

Recommended approach to getting short/abbreviated timezone name

For example:

Getting "EST" from "America/New_York".

This was possible via https://package.elm-lang.org/packages/Bogdanp/elm-time/1.4.0/Time-TimeZone#abbreviation, but that package does is not compatible with Elm 0.19.1. Is adding such support here feasible? Otherwise, is a JS solution via ports the only viable approach?

Support time data before 1970

Hey there Justin!

The beginning of 1970 is just an arbitrarily chosen moment so that UTC/Unix time can have something to be relative to. In the context of many possible uses of time-moments, it's not really that long ago.

But for some reason, it looks like your code deliberately drops data from before 1970. Why is that? Am I correct in assuming that this means all times interpreted via this database are not reliable if they are pre-1970? Can we remove this limitation?

Thanks!