Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upTime.every returns the current date in Unix time. Is this intended? #934
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
process-bot
Jan 3, 2018
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!
Here is what to expect next, and if anyone wants to comment, keep these things in mind.
process-bot
commented
Jan 3, 2018
|
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it! Here is what to expect next, and if anyone wants to comment, keep these things in mind. |
evancz
added
the
docs
label
Mar 7, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
May 22, 2018
Member
Yes, this is the intended behavior. All the time stuff is moving to https://github.com/elm-lang/time in the next release of Elm, and I think that the new API clarifies a lot of things around POSIX time, time zones, etc.
|
Yes, this is the intended behavior. All the time stuff is moving to https://github.com/elm-lang/time in the next release of Elm, and I think that the new API clarifies a lot of things around POSIX time, time zones, etc. |
ElectricCoffee commentedJan 3, 2018
I was doing the clock example in the Elm guide, and I couldn't for the life of me understand why the current time was displayed in the trillions (1514937456820 at the time of writing).
I was pulling my hairs out for about 15 minutes trying to figure out why the number was this huge.
The documentation for Time doesn't mention anything about the format, but based on a hunch I pasted the value into a Unix time converter and got the current date and time (Tuesday, 2 January 2018 23:57:36.820).
Skimming through the source code, it seems that
Time.everyis only supposed to increment a value every time a given interval passes, making no obvious mention of the fact that the starting value is the current Unix time in milliseconds.I don't know if this is the intended behaviour, and if it is, it certainly isn't very well documented.