Implement `toString` for `Date`

[rgrempel]

Consider

toString (Date.fromTime 1422777600000)

Before this pull request, it results in:

{}

After this pull request, it results in:

Sun Feb 01 2015 02:00:00 GMT-0600 (CST)

[rgrempel]

One additional consideration has now occurred to me, concerning the purity of toString in the context of a Date.

The code I submitted calls Javascript's toString() on the date. This seemed like a reasonable default string representation (as opposed to some more specific formatting of the date).

However, toString() does return a different string depending on what the Javascript runtime thinks your local timezone is. So, different computers in different timezones will get different results. Furthermore, it's probably the case that changing the timezone on your local machine would change the results. (By this, I mean manually changing what timezone you are in, via system preferences or the like).

So, I could imagine an argument that it would be better to use toUTCString() instead of toString(), since that will definitely always return the same string.

I would be happy to modify the PR if toUTCString() is considered to be better. The only reason that I don't do it immediately is that:

• People will probably expect to see the stringified Date in the local time zone.
• The function is only impure in odd circumstances.

However, I would certainly understand if it seemed better to avoid even an attenuated impurity.

[rgrempel]

One additional consideration has now occurred to me, concerning the purity of toString in the context of a Date.

The code I submitted calls Javascript's toString() on the date. This seemed like a reasonable default string representation (as opposed to some more specific formatting of the date).

However, toString() does return a different string depending on what the Javascript runtime thinks your local timezone is. So, different computers in different timezones will get different results. Furthermore, it's probably the case that changing the timezone on your local machine would change the results. (By this, I mean manually changing what timezone you are in, via system preferences or the like).

So, I could imagine an argument that it would be better to use toUTCString() instead of toString(), since that will definitely always return the same string.

I would be happy to modify the PR if toUTCString() is considered to be better. The only reason that I don't do it immediately is that:

• People will probably expect to see the stringified Date in the local time zone.
• The function is only impure in odd circumstances.

However, I would certainly understand if it seemed better to avoid even an attenuated impurity.

[Dremora]

It's worth noting that most functions in the Date module are impure in a way that they also depend on machine's timezone (e.g. Date.hour). For consistency, toString should also maintain similar behaviour. Alternatively, everything should be changed to ignore the time zone by switching to getUTC*() methods.

In either case many applications actually require dynamic timezone (e.g. when timezone is stored somewhere in preferences or next to the timestamp) — something that's not supported by the core library, so the choice made here, as long as it's consistent, might not be that important.

[Dremora]

It's worth noting that most functions in the Date module are impure in a way that they also depend on machine's timezone (e.g. Date.hour). For consistency, toString should also maintain similar behaviour. Alternatively, everything should be changed to ignore the time zone by switching to getUTC*() methods.

In either case many applications actually require dynamic timezone (e.g. when timezone is stored somewhere in preferences or next to the timestamp) — something that's not supported by the core library, so the choice made here, as long as it's consistent, might not be that important.

[rgrempel]

That's a good point -- it helps me see why my intuition was that using the local timezone for toString made sense.

[rgrempel]

That's a good point -- it helps me see why my intuition was that using the local timezone for toString made sense.

[jvoigtlaender]

In a related issue, #481 (now closed as duplicate), @fredcy used the following test program. Might be useful over here as well:

import Date
import Effects
import Html exposing (li, text, ul)
import StartApp
import Time

app =
  StartApp.start
    { init = ( 0, Effects.none )
    , inputs = [ Time.every <| Time.second * 5 ]
    , update = \t -> always ( t, Effects.none )
    , view = always showTime
    }

showTime t =
  ul
    []
    [ li [] [ t |> toString |> text ]
    , li [] [ t |> Date.fromTime |> toString |> text ]
    ]

main = app.html 

[jvoigtlaender]

In a related issue, #481 (now closed as duplicate), @fredcy used the following test program. Might be useful over here as well:

import Date
import Effects
import Html exposing (li, text, ul)
import StartApp
import Time

app =
  StartApp.start
    { init = ( 0, Effects.none )
    , inputs = [ Time.every <| Time.second * 5 ]
    , update = \t -> always ( t, Effects.none )
    , view = always showTime
    }

showTime t =
  ul
    []
    [ li [] [ t |> toString |> text ]
    , li [] [ t |> Date.fromTime |> toString |> text ]
    ]

main = app.html 

[jinjor]

I ran into this problem too.

The current toString does not even say it is a Date. I thought my date value was invalid. I confirmed several times that I correctly passed Unix time in millisecond and it is not before 1970. And I finally found it was a problem of toString.

[jinjor]

I ran into this problem too.

The current toString does not even say it is a Date. I thought my date value was invalid. I confirmed several times that I correctly passed Unix time in millisecond and it is not before 1970. And I finally found it was a problem of toString.

[avh4]

According to the docs, "When you view the resulting string, it should look just like the value it came from."

That suggests that toString (Date.fromTime 1422777600000) should equal "Date.fromTime 1422777600000"

But I don't think that's really what anyone here is looking for. When people want toString for Date, there are different things they usually want:

1. view date values while debugging - they probably want to see either ISO format or the date in their locale or the date in an English locale
2. serialize date values - they probably want ISO format, and they probably want to deserialize it later
3. display dates in their UI - they probably want the date in the current locale, or they want more flexible formatting options

Which are we trying to address? and which of these needs is it appropriate to use toString for?

[avh4]

According to the docs, "When you view the resulting string, it should look just like the value it came from."

That suggests that toString (Date.fromTime 1422777600000) should equal "Date.fromTime 1422777600000"

But I don't think that's really what anyone here is looking for. When people want toString for Date, there are different things they usually want:

1. view date values while debugging - they probably want to see either ISO format or the date in their locale or the date in an English locale
2. serialize date values - they probably want ISO format, and they probably want to deserialize it later
3. display dates in their UI - they probably want the date in the current locale, or they want more flexible formatting options

Which are we trying to address? and which of these needs is it appropriate to use toString for?

[rgrempel]

I don't think that we could serve purpose 3 well, since we've got no additional parameters to work with when using toString.

I would probably suggest working with Json.Encode and Json.Decode for purpose 2, since we don't, in general, have a deserializer that corresponds to toString.

Which leaves purpose 1.

But my own goal was to make toString less partial.

[rgrempel]

I don't think that we could serve purpose 3 well, since we've got no additional parameters to work with when using toString.

I would probably suggest working with Json.Encode and Json.Decode for purpose 2, since we don't, in general, have a deserializer that corresponds to toString.

Which leaves purpose 1.

But my own goal was to make toString less partial.

[fredcy]

I wanted it for debugging, for easy Debug.log usage. It might serve for prototyping a UI. But any production usage for avh4's items 2 and 3 would seem to require explicit date-to-formatted-string conversion.

[fredcy]

I wanted it for debugging, for easy Debug.log usage. It might serve for prototyping a UI. But any production usage for avh4's items 2 and 3 would seem to require explicit date-to-formatted-string conversion.

[rgrempel]

I have rebased this against the current master.

[rgrempel]

I have rebased this against the current master.

[evancz]

I was messing with this stuff on my flights yesterday and did something like this in 9bc52e6

[evancz]

I was messing with this stuff on my flights yesterday and did something like this in 9bc52e6