Custom timer module

[Jesper Louis Andersen]

On Tue, Jan 21, 2020 at 3:57 PM Roger Lipscombe <roger@REDACTED>
wrote:

> Unless your timestamps are *intended* to be in user's local time. This
> is a problem with (e.g.) remote management/deployment solutions: the
> user actually *wants* their OS upgrade to be scheduled in their
> timezone, according to the daylight saving rules for then, not now.
>

That is a separate problem in my book.

Your system will have an internal representation, which you should treat as
abstract/unknown. And there is an external representation which you use to
enter and extract points-in-time. If you want an OS upgrade to happen at
02:00am ET, you then provide that to your marshal function, and it converts
that to your internal representation. If you want this point-in-time in,
say, CET, you then extract it from the internal representation into a
string where CET is the timezone.

You can choose any internal representation and reference. {Mega, Secs,
Micro}, nanoseconds, gregorian basepoint, 1/1 1970 basepoint, floating
point, a record, ... as long as you can marhsal/unmarshal.

However, there are some internal representations which are going to be
easier to work with. UNIX uses seconds after 1/1 1970, and keeping that at
UTC makes things a tad easier as well in the long run. Consider if the
machine roams. Now you can do:

$ TZ='EST' /bin/date
Tue 21 Jan 2020 10:32:40 AM EST
$ TZ='CET' /bin/date
Tue 21 Jan 2020 04:32:57 PM CET

This is also useful if multiple people are using the machine, but from
different time zones. It is the same internal representation, but our
presentation changes and switches based on where we are located. If you
make the choice your internal representation moves with the timezone, and
you have a roaming system, then you have to rewrite all timestamps on
timezone changes. Or you have to keep a non-UTC timezone as the base, but
this is not common. Non-UTC timezones are also a hassle if you ever need to
combine log files from multiple data center locations each running with
their own timezone.

My experience is that it is often easier to do this conversion in the
border of your system and then work with a UTC-reference internally.
Otherwise, you end up with the need to do conversions on demand in your
code. This is certainly doable in languages with type systems, as the type
system can protect you against incorrect use. But in a uni-typed world
where everything is a term, you usually want a simple representation.




-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200121/06abb965/attachment.htm>