Posted by
Pete McBreen
27 Oct 2019 at 22:38
Looking back over Kyle Wilson’s Software Is Hard post from way back in 2007, I was reminded about how bad we are at estimating software projects. As the article hinted at, we can get reasonable estimates for software we have previously developed, but there is little value in redeveloping existing software.
You never have to solve the exact problem that someone’s solved before, because if software already existed that solved your need, you wouldn’t have to write it. Writing software is expensive. Copying software is cheap.
In case anyone thinks that this lesson from 12 years ago is no longer relevant, think of the multiple promises that have been made for autonomous cars in recent years and compare that to the performance of the recently released Smart Summon feature in Teslas. There are multiple videos out there of cars driving tentatively or erratically in a parking lot, and we think that soon these cars will be ready to drive unattended on a public highway?
On a historical note, Consumer Reports back in early 2016 reported on the self parking feature, and now in late 2019, Consumer Reports suggests that Tesla Owners are Beta Testers.
Posted by
Pete McBreen
02 Oct 2019 at 22:29
Turns out this is non-trivial, as Elixir ships with partial support for timezones, as documented by Lau Taarnskov, the creator of the Tzdata library.
First thing is to add the tzdata to mix deps
{:tzdata, "~> 1.0.1"},
Then have to set ecto to use utc_datetime (microseconds not needed for simple table updates)
@timestamps_opts [type: :utc_datetime]
At this point, no matter what timezone you are in, an update will store the UTC time in the database, and show that UTC time on the web page, which although correct is not all that useful. Annoyingly querying for a timestamp in pgAdmin, will transparently shift any timestamp with time zone column to show the local time, but when displayed on the web page it will show the UTC time with a Z after the time as in “2019-10-02 21:58:15Z” rather than the local time of “2019-10-02 15:58:15”
The fix for this is to use DateTime.shift_zone/3 (shift_zone!/3 coming in Elixir 1.10), for now that code can live in the view
def format_timestamp(timestamp, time_zone) do
timestamp
|> shift_zone(time_zone)
|> raw
end
defp shift_zone(timestamp, time_zone) do
case DateTime.shift_zone( timestamp, time_zone) do
{:ok, dt} -> NaiveDateTime.to_string(DateTime.truncate(dt, :second)
{:error, _dt} -> NaiveDateTime.to_string(DateTime.truncate(timestamp, :second)) <> " UTC"
end
end
And then in the template you can just use this to format the timestamp correctly for the appropriate timezone
<%= format_timestamp(subject.updated_at, "MST7MDT") %>
My timezone is MST7MDT, but it will be better to pull it in from the user’s browser using some JavaScript and push it into the session, or have it as a configurable value on the user profile. Luckily all modern browsers now have a simple way to get the timezone from the browser…
const tz = Intl.DateTimeFormat().resolvedOptions().timeZone;
Please note that to be safe, the shift_zone function will return the UTC time if the timezone passed in is not recognized.
