Hello,
I want to get the local time zone delta and pass it to the server, so that the server returns time of events in that zone. I know how to get the local time zone using Task.perform. Doing that I get (when logged to console) Zone -240 []. How do I extract the -240?
I tried pattern matching with Time.Zone x y = Zone - 240 []. But that does not work, presumably because what I am seeing is the string representation. But then how do I extract the -240?
Thank you.
Zone seems to be an opaque type, so you’d need helper functions provided by the package for you to get information out of it; can’t pattern match extract it yourself.
However, you can try diffing with toHour and toMinute (and toDay) against Time.utc to sniff out the information
The package https://package.elm-lang.org/packages/justinmimbs/time-extra/1.1.0/Time-Extra Has a toOffset Function that will get what you want.
Thanks @choonkeat. Yes, that would work.
Thank you @cjmeeks. Yes, I will look into that. But I was hoping I could avoid using 3rd party packages.
and month, and year… lol. that toOffset looks good actually; comes with tests too
A word of caution: it’s generally better to have the server not care about time zones and always send time information in utc.
Why do you want to do it this way?
Thanks @norpan. I will think about this more, and perhaps I will keep all the time zone conversion and time display on the client side. The reason I was asking is the following:
I want to display various times to the client time in their local time zone. Currently, I get the timestamp from the server in utc and do the conversion on the client.
However, formatting the time for display to the client takes many more lines of code than I would need if I were using Postgres’ methods for time formatting and time extraction. Hence, the question whether I could send that information to the server and have it done there.
In that case, I suggest you not send the time zone diff but the time zone name (with getZoneName) and have the server use the name and its own tz database instead of a time diff (which is unreliable since it can vary over the year).
I agree, keeping everything in UTC and just converting for display purposes is the most consistent and least error prone way to do it, and would recommend following that first. There are reasons you might want to depart from that and use local times instead - it depends though on what you are doing. So here are some examples:
Sometimes the opera is broadcast live and people around the world can watch it in their local cinema in addition to the audience watching the live performance. So we have an app that tells users the timetable for these events. The show is on in New York starting at 7pm local time there. In UTC that is 12 midnight. A cinema in San Fransisco is showing it, and the start time there will be 4pm. Broadcasting means that this event is taking place at the same moment all over the world, so using UTC as a common currency to translate accross time zones makes sense.
You go on holiday and book a hire car to collect at the airport. You know your flight is due to get in at 11 and its going to take a while to get out of the airport so you put 11:30 as the collection time for the car. It doesn’t really make sense to translate this into UTC as it is a local event only. If you translate it into UTC and email the user to remind them of the pick up time in their home local time the message might say “remember your car booking at 03:30”. In that case you probably don’t even want to use Time.Posix although it does not contain the timezone so can be used for local times. I would just create my own data type to hold the local times for this application:
type alias LocalTime =
{ hour : Int
, minute : Int } -- That's all thats really needed for the car rental app.
Hope that helps you to decide which way is best for your particular application.
In cases like that I prefer to store in UTC and keep the time zone as additional data, that way you get the best of both worlds.
The only instance where we store time “locally” is for repeated events, like “coffee break each day at 3 pm”.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.