Discussion about initial time and time zone values

Learn
1

If an application needs time, the startup is not easy, because Tasks are used, there is no time and time zone available. I think starting with defaults like time 0 and utc is not correct, because it is not true. Having these values typed as Maybe will lead to complexity when handling with time other parts of the code, but should be the solution, that is necessary. There is also a workaround, to use Javascript and pass those values as flags.

I noticed the guide is starting with Model Time.utc (Time.millisToPosix 0). One could argument it’s to keep things simple.

Also the realworld elm-spa-example is ignoring the time zone.

Are those examples indicators, that there is need for a way an api change to support those use cases?

Interestingly a non-exisiting Browser.Env was mentioned with time zones in the past.

1 Like
2

To make this even worse, it is impossible to get current timezone in JavaScript (see note at Time.here).

But if I were to ignore that, and wanted to use the incorrect timezone returned by Time.here, then I think I’d do something like:

type Model
    = Uninitialized
    | Initialized InitializedModel

type alias InitializedModel =
    { time: Time.Posix
    , timezone: Time.Zone
    , ...
    }

This way there are no Maybe:s, and only few top level functions needs to pattern match on Model, and will then pass inner InitializedModel to those lower level functions which are only used after initialization has been done.

3

Thanks, I forgot about this approach. It’s essentially moving the Maybe up. Made clear with this renaming:

type MaybeModel
    = NothingModel
    | JustModel Model
4

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.