-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
format is not pure #41
Comments
new Date() is impure, but format is not. when I call new Date(0) in london I get |
I don't think that's right, @cullophid. Essentially a Date object just wraps a number:
We can get from > new Date(0).toISOString()
'1970-01-01T00:00:00.000Z' We can also extract components from the Date object in a pure fashion: > new Date(0).getUTCHours()
0 As soon as we use anything time-zone dependent, all bets are off: > new Date(0).getHours()
16
The impurity lies in |
@TheLudd @davidchambers I stand corrected :) new Date(n) is pure, but date.getMonth() isn't... Right? It might make sense to change the lib to use UTC methods instead. off the top of my head I see a few possible solutions.
or maybe
what do people think? |
forcing the user to explicitly stating the timezone might actually make it simpler to work with js dates. |
Agrees The reason I discovered the error is that we are migrating from moment to date-fp and I found that the same timestamp was showing differently on different pages. I had just never considered the time zone. I am not sure what format of your options to use but would it not be easier to work with offset instead of names like "CET"? |
@TheLudd I agree, but I often find that when the decision is between simple and easy, simple is the right decision. I agree that offset would probably be simpler than timezone names. adding a timezone param doesn't necessarily make the lib that harder to use. You could do something like:
|
I think we are actually only talking about 4 functions |
What about But then again, what if time zone is not supplied. Then parse must assume UTC, correct? |
I would say so... I could see some use cases for parsing based on a specified timezone... |
Well, use cases aside if |
Well parse could just assume UTC unless an other timezone is specified: Currently parse is not pure, since it assumes the current year if no year details are given. There seems to be a lot to address here. :) |
Perhaps assume 1970 instead? |
Yeah i think that makes sense. |
Wouldn't the user then need to determine whether DST applies to each date? |
@davidchambers... But if we just sat "CET" then THW function still isnt pure... |
Hmm purity might come at a high price in this case |
The way I see it is this: |
What does THW mean? I don't see a problem with taking a time zone identifier as an argument. We should be able define pure functions with types such as getHour('Pacific/Auckland', new Date(0)) Maintaining time-zone tables is a lot of work, though, which is why programming languages usually don't include time-zone databases in their standard libraries. |
@davidchambers Would I agree with @TheLudd that purity is essential, but I would also want the common use cases to be easy. |
So far I think we all agree that functions should be pure. The final thing we need to decide is how we manage timezones. |
+1 for using timezoneOffset |
I'm confused.
I believe what you're suggesting is this: // date :: Date
const date = ...;
// hour :: Integer
const hour = getHour(date.getTimezoneOffset(), date); We can't use > new Date().getTimezoneOffset()
420
> new Date(0).getTimezoneOffset()
480 But what if my program is running in San Francisco but I want to get the hour of It seems to me we have two options:
The first option is very limiting. |
I don't see any way around this without including a timezone database. timezone include the whole IANA time zone database yet they manage to make the minified version of their module only 2.7k so it doesn't have to be a big overhead. |
@davidchambers sorry I meant that |
The time-zone database would need to be aware of DST. |
true, but if the time-zone database is aware of DST isn't it impure? I still think that does that make sense? |
No, it would not. We're providing a Date object as the second argument. This represents a moment in time. Any given moment in time corresponds to exactly one date–time in the Pacific/Auckland time zone. Going in the other direction is quirky (but still pure). There are date–times in the Pacific/Auckland time zone which correspond to two moments in time. One day each year 02:30 occurs twice: once before and once after the one-hour adjustment. If we are asked to determine the moment in time corresponding to 02:30 local time on such a day, we must arbitrarily (but consistently) choose either the first 02:30 or the second one.
I don't see how this is helpful. When dealing with |
@davidchambers Ah ofc! no there is not reason for a timezone helper function if That sounds like a strategy to me... what do we do for the common case of |
We could provide an impure function such as |
Sounds good
|
@davidchambers Thanks for explaining the detail. The timezone issue is more complicated then I thought. I have learnt a lot from your comments :) |
Hi guys sorry it has taken me so long to get any thing done on this I think i prefer this to adding a timezone argument to every function call for get, set, isLeapYear, etc. |
I opened a PR (NOT READY TO BE MERGED) |
Fixed in version 5.0.2 |
format
may return different values depending on who uses it or where.For me, living in Sweden,
format('HH:mm', new Date(0)) === '01:00'
. It really should be'00:00'
. I suspect that people from different parts of the world will have varying results.Thoughts?
The text was updated successfully, but these errors were encountered: