Git Product home page Git Product logo

elm-date-extra's People

Contributors

aherranz avatar athanclark avatar bartsokol avatar besuikerd avatar brianhicks avatar brunogirin avatar chalmagean avatar chiptunes avatar cuducos avatar decafbad avatar dynajoe avatar fdbeirao avatar frankschmitt avatar geekfish avatar ikr avatar jinjor avatar karls avatar kkpoon avatar neverwintermoon avatar ohanhi avatar rluiten avatar robertjlooby avatar ryan-senn avatar sindreij avatar srolel avatar tvv avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

elm-date-extra's Issues

Format date seems to use incorrect offset

Here's a test that fails for me. I'm currently in CDT.

convertingDates : Test
convertingDates =
  suite
    "Converting a date to ISO String"
    [ test
        "output is exactly the same as iso input"
        (assertEqual
          (Ok "2016-03-22T17:30:00.000Z")
          (Date.fromString "2016-03-22T17:30:00.000Z" `Result.andThen` (Ok << dateToISO))
        )
    ]

The output is 2016-03-22T18:30:00.000Z instead of 2016-03-22T17:30:00.000Z.

dateFromFields with hour = 0

I'm getting a strange effect from dateFromFields when hour is set to 0. The doc says “Hours are input in 24 hour time range 0 to 23 valid. Returns dates in current time zone.” But watch this:

import Date.Extra.Format exposing (..)
import Date exposing (..)
import Date.Extra.Create exposing (..)
d = dateFromFields 2016 Jul 8 0 0 0 0
isoString d       -- "2016-07-08T01:00:00.000-0400" : String
hour d            -- 1 : Int

My time zone is indeed -0400:

> (new Date()).getTimezoneOffset()
240

but it's turning hour zero into hour 1. It does that all the way up the clock:

> isoString <| dateFromFields 2016 Jul 8 4 0 0 0
"2016-07-08T05:00:00.000-0400" : String
> isoString <| dateFromFields 2016 Jul 8 13 0 0 0
"2016-07-08T14:00:00.000-0400" : String
> isoString <| dateFromFields 2016 Jul 8 22 0 0 0
"2016-07-08T23:00:00.000-0400" : String
> isoString <| dateFromFields 2016 Jul 8 23 0 0 0
"2016-07-09T00:00:00.000-0400" : String

So I can provide hour 23 to get zero, but it's the next day. I also tried -1, but it clamps it to 1.

The offset issue reminds me of what's discussed in #6, but it looks like the solution there has to do with the syntax of the offset when parsing. Here I'm bypassing any parsing and trying to construct a date directly.

Questions: I cant see to find a method to find next date.

I cant see to find a method to find next date.
Does this method exist?

I can write it myself but I wondered if it exists

nextDate : Date -> Date
nextDate date
    Date.fromTime ((Date.toTime date) + 1000 * 60 * 60 * 24)

prevDate : Date -> Date
prevDate date
    Date.fromTime ((Date.toTime date) + 1000 * 60 * 60 * 24)

Huge RAM consumption when calling Date.Extra.Utils.dayList with a negative integer.

I just discovered this unusual behavior to the dayList function which is defined as:

dayList : Int -> Date -> List Date

Calling Date.Extra.Utils.dayList -2 someDate, creates a huge immediate bump into RAM consumption. Then the hole app gets frozen.

For positive numbers it works as expected. But I by mistake was getting a negative integer by calling:
Date.Extra.Duration.diffDays startDate endDate

Date.Extra.Compare takes time into account

An example here: https://ellie-app.com/qbFnhQG4ba1/0

I mistakenly expected Date.Extra.Compare to compare just dates, regardless the time and time zone. As shown in the example above, if we have dates from different sources (like parsing a string and constructing a date by hand), this function will not work as expected.

The supposed user workaround is reconstructing a date from fields before comparison, but I believe this logic should be somehow included in comparison functions themselves.

Test suite fails to run

Running tests with elm-test (installed with npm -g) 0.18.12 results in

Success! Compiled 0 modules.
Successfully generated /dev/null
Success! Compiled 1 module.
Successfully generated /home/ikr/prj/elm-date-extra/elm-stuff/generated-code/elm-community/elm-test/elmTestOutput.js
CreateTests currentOffsets: (-120,-60)
CreateTests currentOffsets: (-120,-60)
CreateTests currentOffsets: (-120,-60)
CreateTests currentOffsets: (-120,-60)
CreateTests currentOffsets: (-120,-60)
CreateTests currentOffsets: (-120,-60)
CreateTests currentOffsets: (-120,-60)
CreateTests currentOffsets: (-120,-60)

elm-test 0.18.12
----------------

Running 324 tests. To reproduce these results, run: elm-test --fuzz 100 --seed 1515671661

↓ Date.Extra.CreateTests
✗ Create module tests

    This `describe "Create.getTimezoneOffset - each describe PASSES in matching time zone ONLY."` has no tests in it. Let's give it some!


↓ Date.Extra.DurationTests
✗ Date.Duration tests

    This `describe "Duration.add"` has no tests in it. Let's give it some!


↓ Date.Extra.DurationTests
✗ Date.Duration tests

    This `describe "Duration.diff"` has no tests in it. Let's give it some!


↓ Date.Extra.DurationTests
✗ Date.Duration tests

    This `describe "Duration.diffDays"` has no tests in it. Let's give it some!


↓ Date.Extra.UtilsTests
✗ Date.Utils tests

    This `describe "Utils.isoWeek - test in matching time zones only."` has no tests in it. Let's give it some!



TEST RUN FAILED

Duration: 309 ms
Passed:   319
Failed:   5

Looks like tests are conditionally included. When the condition isn't met, a stub tests-set gets registered for execution. Those stubs make elm-test unhappy, it seems.

It all started for me with finding a problem with Duration.diff, and wanting to write a reproducing test. However I failed in making the tests run.

Problem with dayList

I have the following line of code:
Debug.log "dayList" <| dayList (daysInMonth 2017 10) <| dateFromFields 2017 10 1 0 0 0 0

And when I open the browser I see this in console:
dayList: [
<Sun Oct 01 2017 00:00:00 GMT+0200 (CEST)>,
<Mon Oct 02 2017 00:00:00 GMT+0200 (CEST)>,
<Tue Oct 03 2017 00:00:00 GMT+0200 (CEST)>,
<Wed Oct 04 2017 00:00:00 GMT+0200 (CEST)>,
<Thu Oct 05 2017 00:00:00 GMT+0200 (CEST)>,
<Fri Oct 06 2017 00:00:00 GMT+0200 (CEST)>,
<Sat Oct 07 2017 00:00:00 GMT+0200 (CEST)>,
<Sun Oct 08 2017 00:00:00 GMT+0200 (CEST)>,
<Mon Oct 09 2017 00:00:00 GMT+0200 (CEST)>,
<Tue Oct 10 2017 00:00:00 GMT+0200 (CEST)>,
<Wed Oct 11 2017 00:00:00 GMT+0200 (CEST)>,
<Thu Oct 12 2017 00:00:00 GMT+0200 (CEST)>,
<Fri Oct 13 2017 00:00:00 GMT+0200 (CEST)>,
<Sat Oct 14 2017 00:00:00 GMT+0200 (CEST)>,
<Sun Oct 15 2017 00:00:00 GMT+0200 (CEST)>,
<Mon Oct 16 2017 00:00:00 GMT+0200 (CEST)>,
<Tue Oct 17 2017 00:00:00 GMT+0200 (CEST)>,
<Wed Oct 18 2017 00:00:00 GMT+0200 (CEST)>,
<Thu Oct 19 2017 00:00:00 GMT+0200 (CEST)>,
<Fri Oct 20 2017 00:00:00 GMT+0200 (CEST)>,
<Sat Oct 21 2017 00:00:00 GMT+0200 (CEST)>,
<Sun Oct 22 2017 00:00:00 GMT+0200 (CEST)>,
<Mon Oct 23 2017 00:00:00 GMT+0200 (CEST)>,
<Tue Oct 24 2017 00:00:00 GMT+0200 (CEST)>,
<Wed Oct 25 2017 00:00:00 GMT+0200 (CEST)>,
<Thu Oct 26 2017 00:00:00 GMT+0200 (CEST)>,
<Fri Oct 27 2017 00:00:00 GMT+0200 (CEST)>,
<Sat Oct 28 2017 00:00:00 GMT+0200 (CEST)>,
<Sun Oct 29 2017 00:00:00 GMT+0200 (CEST)>,
<Sun Oct 29 2017 23:00:00 GMT+0100 (CET)>,
<Mon Oct 30 2017 23:00:00 GMT+0100 (CET)>]

Interesting lines are the two last ones. October 29 is mentioned twice. I think this is because of the time change in October. But I think this is a bug because the name of the function is "dayList" which clearly doesn't return what it says. I ended up using List.uniqueBy Date.day from list-extra package on the result.

Date.Extra.Format.isoString isn't parsable in Safari.

I'm building an elm app that builds a Date.Date from two different sources, and gets the local timezone to submit to a server in an iso8601 format. To extract the local timezone, I was originally doing:

localTimeZone : String
localTimeZone =
  (Date.fromTime 0)
    |> Date.Extra.Format.isoString
    |> String.right 5
    -- Result : -0500

Later, I combine my date and time parts with this local timezone and do a Date.fromString which I'm guessing backs onto javascript's Date implementation. This works perfectly fine in Chrome and Firefox, but Safari throws an error saying the date I assembled isn't a proper 8601 format.

After some fiddling, I discovered Safari would only accept a timezone if it was formatted with a : between the hour and minute, ie 1999-01-01T12:00:00-05:00.

Would it be possible to have isoString output with that format, as it can be parsed on all browsers using Date.fromString from elm's core packages.

dateFromFields and timeFromFields documentation could be improved

The documentation only contains the signature of the function, but no usage example or explanation of each parameter.

dateFromFields
    :  Int
    -> Month
    -> Int
    -> Int
    -> Int
    -> Int
    -> Int
    -> Date

timeFromFields : Int -> Int -> Int -> Int -> Date

What are all those Ints? What does each mean? Based on this documentation a user might try to create a date in the US format like this:
dateFromFields 02 Feb 2018 13 52 0 0 0
I also cannot tell what the last two numbers are without looking at the source.
The same applies to timeFromFields.

AM/PM is wrong for 12 noon

12 noon in the US is PM but the formatter reports it as AM.

This time 1456506529321 is formatted as 26 Feb 2016 12:08:49 AM with format:

%-d %b %Y %-H:%M:%S %p

but it should be PM

Swedish localization not found

I just installed your package and wanted to use the newly added Swedish localization. Though the compiler cannot find the module Date.Extra.Config.Config_sv_se and looking in the elm_stuff folder and your package there are no such file. I can see it in your repo though.

Months subtraction

There's an issue with month subtraction. Repro steps:

import Date exposing (fromTime)
import Date.Extra.Duration exposing (Duration(..), add)
today = fromTime 1499529702655
add Month -7 today -- results in Dec 08 2016, which is right
add Month -19 today -- results in Dec 08 2014, which is one year to the past wrong
add Month -20 today -- results in Nov 08 2015, which is right again

Seems that problem is with the yearOffset in the addMonth function, but I'm not sure. I'll probably do some work on this.

Update

Further investigation showed that the root problem is in the Internal.daysFromCivil. When targetMonthInt equals zero resulting year is reduced by one (which is logical and right behavior). But when newMonthInt is simultaneously less than zero (in case of subtracting 12 + currentMonthNumber months or more) it leads to additional year subtraction from yearOffset.

I'll be making a PR now.

French localization 24h

Hi,

First, thank you for this great package!

I used the french (from France fr_fr) locale to display my date and times but there is a little error in the format: french times are displayed on 24 hours without AM/PM.

dateFromFields slow

Elm 0.16 (core) has no way, I know of, to initialize a date except with a string or the timestamp and is also missing date manipulation functionality. So I found your package, which contains all the functionality I need. However the way dateFromFields is converting the date very slow. I have to deal with a lot of Dates and calculations/checks of them so this really hurts the overall application performance.

On my machine initialization of a Date with dateFromFields and year 1975 requires about 5ms and with year 2016 it takes 28ms. Native JS new Date(year, ...) requires always about 0.02ms.

Can you somehow improve the performance of your elm algorithm or maybe add a initialization with native functionality, or should I file a issue on elm-core to provide native date initialization functionality?

Unify i18n

Hello, shouldn't we unify the format for the i18n ?

  • I_en_us.elm have first letter uppercase
  • I_fr_fr.elm all words are in lowercase

Utils.isoWeek may return wrong results

I've noticed that Utils.isoWeek may return wrong week number. Here's an example:

> sep12 = Utils.unsafeFromString "2016-9-12"
<Mon Sep 12 2016 00:00:00 GMT+0300 (EEST)> : Date.Date
> Utils.isoWeek sep12
(2016,36,1) : ( Int, Int, Int )
> Utils.isoWeek (Utils.unsafeFromString "2016-9-13")
(2016,37,2) : ( Int, Int, Int )
> Utils.isoWeek (Utils.unsafeFromString "2016-3-21")
(2016,12,1) : ( Int, Int, Int )
> Utils.isoWeek (Utils.unsafeFromString "2016-3-28")
(2016,12,1) : ( Int, Int, Int )

I'm quite sure the issue is daylight saving time. Basically, isoWeek returns wrong week number for all summer time Mondays. (Also here's a good write up on the same problem with JS Date: http://blog.synyx.de/2012/11/properly-calculating-time-differences-in-javascript/). This also affects Period.diff:

> Period.diff (Utils.unsafeFromString "2016-3-21") (Utils.unsafeFromString "2016-3-14")
{ week = 1, day = 0, hour = 0, minute = 0, second = 0, millisecond = 0 }
    : Date.Extra.Period.DeltaRecord
> Period.diff (Utils.unsafeFromString "2016-3-28") (Utils.unsafeFromString "2016-3-21")
{ week = 0, day = 6, hour = 0, minute = 0, second = 0, millisecond = 0 }
    : Date.Extra.Period.DeltaRecord

As far as I know, Elm doesn't have a good support for UTC yet (https://github.com/elm-lang/core/issues/486), so maybe it would be acceptable workaround to use round when calculating day difference between dates for now?

Period.add (Period.Delta (Period.diff d1 d2)) 1 d2 /= d1

Hi,

According to Period.diff documentation:

diff : Date -> Date -> DeltaRecord

Return a Period representing date difference. date1 - date2.

If you add the result of this function to date2 with addend of 1 will return date1.

but when performing the following test in elm-repl, I don't get date1 when adding Period.diff date1 date2 to date2:

> import Date
> import Date.Extra.Create as Date
> import Date.Extra.Period as Period

> d1 = Date.dateFromFields 2018 Date.Sep 29 0 0 0 0
<Sat Sep 29 2018 00:00:00 GMT+0200 (CEST)> : Date.Date

> d2 = Date.dateFromFields 2017 Date.Nov 2 0 0 0 0
<Thu Nov 02 2017 00:00:00 GMT+0100 (CET)> : Date.Date

> Period.diff d1 d2
{ week = 47, day = 1, hour = 0, minute = 0, second = 0, millisecond = 0 }
    : Date.Extra.Period.DeltaRecord

> Period.add (Period.Delta (Period.diff d1 d2)) 1 d2
<Fri Sep 28 2018 01:00:00 GMT+0200 (CEST)> : Date.Date

Did I miss something?

Thank you

Year?

Core date offers years as an option for neither Period nor DeltaRecord and I'm touching year differences in some of my own code -- currently there's no convenience for it. 52 weeks and 365 days aren't very exact values to divide against...

Period diff example

I'm having trouble understanding how best to extract data out of Date.Period.diff. It seems you must always "case result of Delta", is that right?

--- this doesn't work
dayDiff : Date -> Date -> Int
dayDiff d0 d1 = (diff d0 d1).day
--- this works, but is clunky
dayDiff : Date -> Date -> Int
dayDiff = 
  case (diff d0 d1) of
    Delta x -> x.day
    _ ->  Debug.crash "Never get here"

Thanks for a super useful library.

Release for Elm 0.19?

We're very happily using this library at work. I don't believe it has been released for Elm 0.19 yet. Could we help with that at all? Are there any blocking issues that you're aware of? I'm guessing unsafeFromString from string might be an issue as it is my understanding that Debug.crash is no longer available?

Problem using period with a timezone

Hi, I'm the author of the article about time manipulation in elm and sorry for the delay of response, I had to rethink like my old self.

I make an Ellie App that still seems to reproduce what my problem was (but having changed DST, only one month is problematic at the moment).

The result of that code is this (it is for 2016):

Jan: 31
Feb: 29
Mar: 30
Apr: 30
May: 31
Jun: 30
Jul: 31
Aug: 31
Sep: 30
Oct: 31
Nov: 30
Dec: 31

Notice that March is displaying only 30 days.

To be fair, it could just be something wrong in my way of calculating the number of days. I was doing it that way to be consistent with my calculation of days without weekend, that I did thusly:

numberOfDaysBetweenNotCountingWeekend : Date -> Date -> Int
numberOfDaysBetweenNotCountingWeekend start end =
    Period.diff start end
        |> (\d -> (d.week * 5) + d.day)
        |> abs
        |> (+) 1

I was using elm-date-extra 8.1.2 at the time, but I tested on Ellie with the 9.0.1 which I assume is the most recent one.

Thanks for asking me to do this, I should have done it form the start :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.