October 30, 2024 • 41 mins
In this episode of Elixir Mix, we’re joined by Lau Tornskau, creator of the tzdata library and prolific Elixir open-source contributor, to talk about how to ensure “correctness” of time-related data in Elixir and how Elixir’s standard library has grown to include native support for handling time zones.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Links
Picks
- Alex - Dynamically Configure Your Plugs at Run-time
- Alex - An IoT Birdhouse with Elixir Nerves & Phoenix LiveView Components
- Bruce- Why Things Fail, a series on failure with Brian Troutwine and Bruce Tate
- Bruce - The Problem with Time & Timezones – Computerphile
- Sophie - You might not need the Calendar or Timex libraries
- Lau - We’re hiring – TheRealReal
- Lau - Domain Modeling Made Functional by Scott Wlaschin
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
So hello and welcome to today's episode of Alixir Mix. Today,
our fabulous panel of hosts includes Bruce Tae Pre Elixir
comp Greetings everybody, Oh yeah, happy, Kreo Alixakov greetings, nice one.
We also are joined by Lars Vikmam Hey Lars. We've
got Mika Khalafiel, Hey everyone, and Alex kutmoas Hey Alex.
(00:29):
And we are joined today by a very professional guest,
Llow Tornsco. Thank you for joining us. Laud and Law
as an engineer at the Real Reel and he's been
doing some writing lately and some speaking on the topic
of daytime in Elixir, everybody's favorite or perhaps most dreaded
topic often in any programming language, date and time. But
(00:50):
before we get into some of the questions that we
have for you, love, if you want to maybe go
ahead and tell us a little bit about yourself and
what brought you into the Elixir community.
Speaker 2 (00:59):
Hello. Yeah, I'm happy to be here on the show.
Speaker 3 (01:02):
So I started doing Alixir around twenty fourteen, and I've
been using different program.
Speaker 2 (01:10):
Languages before that, a lot of Ruby before Elixir.
Speaker 3 (01:14):
One of the things I started looking at was there
was no solution for time zones, and I had previously
had some issues with how data and time.
Speaker 2 (01:23):
Was handled in other languages.
Speaker 3 (01:26):
So I thought, and I thought, this was a new language,
how could I make this more enjoyable to work with
in this new language? Because I saw myself working with
the elixer for a long time, so that was something
I thought that was a problem for me and probably
also for other people. So that's one of the things
I started looking at. And then I've been doing Elixir
(01:50):
ever since, both open soores and working with the professional So.
Speaker 4 (01:55):
Everybody has their little Elixir moment the top that you
kind of looked at the language and uh, hey, that's
that's cool or interesting. I want to know a little
bit more about that. What was your first program or
the first thing that you saw where you think where
you thought this language has a chance to be pretty
cool for me.
Speaker 2 (02:11):
Yeah, now I'm just thinking back. Yeah.
Speaker 3 (02:14):
The funny thing is the the first real library I
wrote was this time zone handling. So yeah, if you
if you look back at the at the code, that
was like.
Speaker 2 (02:23):
Me learning and exerting that and that was the first one.
Speaker 3 (02:27):
I mean, there was there was a little world, but
that was kind of for first real project. The thing
basically I thought I had when I first started using Ruby.
I that was around the time, that was before Rails
was released, and I saw kind of the beginnings of
Rails was one of the reasons I started using Ruby,
and I thought, this is going to be super popular. This,
(02:51):
this is so much better than pH P or Java,
that was another solution for the web before, and there
was different other languages coming along, and I've been of
the mindset that I didn't really want to switch languages
all the time unless something was like ten times better,
because or if something is twenty percent better, it can
(03:15):
be cool to learn it to learn different things. I'm sure, Bruce,
you're all about, you know, learning new learning, learning new
languages and learning new things from that one language. But
this was the language that was I thought was so
much better. Basically it could do. I thought you could
do everything you would want to do with Ruby. You
could do and you could do better with Alixir, just
(03:36):
just in terms of how how simple it is to
understand the programs you write with it. I guess big
thing with it is how it's immutable and how you
can reason about it. So when you have arguments coming in,
you know what you have there you can reason about it,
whereas in Ruby and other object during languages, you have
(03:57):
something and there's a lot of times the groovy dot
dup to make sure no one's knowing nothing else is
messing with what data you have there. So I thought
the functional nature of Elikser was great, and I guess
it felt like something I've been looking for for a
long time and didn't realize it. And then on top
of that, you have, you know, there's so many things
(04:19):
coming together. So on top of that, you have the
concurrency aspect of it, and how it just made sense
with the web and concurrency, and how it was made
for telephone networks that map so well to the Web,
and you have you know, web clients instead of telephones.
And yeah, there's just so many things that made sense
(04:41):
to me.
Speaker 2 (04:41):
So it's hard. It wasn't one thing, it was many
things together.
Speaker 4 (04:46):
That might be the most thoughtful answer I've ever heard
of that question.
Speaker 5 (04:49):
Yeah, I kept a lot and interrupt and be like yes, yes, yes,
yes to all those points and more. I definitely, I
definitely echo all those all those sentiments.
Speaker 2 (04:58):
I mean, from the fact that.
Speaker 5 (04:59):
It's a functional language, but it's a very pragmatic functional language.
Josh Adams isn't with us today, so I can bag
on Haskell a little bit. But yeah, I mean I've
tried Haskell in the past. I always found it a
little too verbose, too difficult to reason about. Again, maybe
it's just not my cup of tea, but I did find,
you know, a lick sort of be a very pragmatic
(05:20):
functional language. And I think camera where I heard it from.
But I think one of the Airline initial designers said
that they made it functional from a like a use
case perspective, not necessarily they sought out to make a
functional language from an academic perspective. They wanted to make
a functional language, or they want to make a language
that could deal with a problem, and functional programming paradigms
(05:40):
kind of helped solve that problem. So it's a very
pragmatic road to that solution that drives with me, and
I think that's why I've stuck around. Yeah, you see
all the heads of everybody kind of nodding. I know
that this is kind of an audio podcast, but yeah,
that's that's kind of cool. And one of the things
that that struck me about that answer is that he
jumped into a new language and said, hey, I'm going
(06:03):
to solve a problem that I recognized in the language
in the language, which is interesting to me because it
takes a lot to recognize as a newcomer where the
weak points are in a language right off the bat,
I don't know that I could do something like that.
Speaker 6 (06:20):
And also just the fact that starting out and going
right for times, dates and basically all the complexity that
most developers absolutely will use the library to avoid and
just like, yeah, i'll work with that.
Speaker 7 (06:38):
Can unpack how that decision making happens, because I don't
quite grasp how you would approach a new language and
decide that that's what you're doing.
Speaker 2 (06:49):
It's impressive.
Speaker 3 (06:51):
Yeah, I think it's because I had so many problems
with how it was handled in other places, so I thought,
at least to begin with, I wanted to think it
came at the same time, At one hand, I wanted
to explore what this problem is generally regardless like of
(07:12):
regardless of the language, like how how is how is
state and time handled? How should it be handled? And
then specifically for Elixir, I wanted to implement some solutions
for that. So I got it was partly being interested
in the subject because it was such a thing. It
was a thing like you say that some people dread
(07:36):
or don't like, but everyone will use it and you
will have to use it. So I thought, this is
something interesting too to look at. How would how would
I want it to be solved? And then I just
started studying it a lot and just kept working on it.
Speaker 2 (07:54):
And also I should mention.
Speaker 3 (07:56):
That now today, many years later, there's a lot more
people working on it. There were also people working on it, uh,
you know, a few people work on it in the beginning,
and and now even more so.
Speaker 2 (08:08):
So that's great to see.
Speaker 3 (08:10):
I thought it was interesting and it's been rewarding and
and and yeah, I thought it was an interesting problem
to solve.
Speaker 4 (08:17):
So I had a coworker's name was James Gray, and
he so a smile on God from LARSA. Yeah, a
good friend of mine, and wrote the book Designing Elixer
Systems with OTP or I guess I wrote it with him,
would be the right way to say that, right, But
but James always said when whenever any one of us
ever dropped a line into the code that did date math,
(08:39):
he would say, no, no, no, there there there are
some problems that you don't try to solve at hoc.
We need libraries. What are some of the common mistakes
that you've seen people make when they try to do
their own roll, their own ad hoc date math.
Speaker 3 (08:57):
I think an important part of this that also so
to step back a bit. The important part of this,
I think is to first think about what you're trying
to achieve. So, for instance, sometimes if you have an
example of a birthday and then you want to calculate
something related to dates, One thing that I thought was
(09:20):
annoying or confusing was how people use the word date
to mean something else than just to date, so you
can have like first, you know, people might say a
common thing that programmers will say sometimes is convert everything
to UTC, and then they will also talk about dates,
and they will have seconds and minacent them and time
(09:42):
zones all of a sudden because it's UTC. So the
thing about converting everything to UTC, first of all, that's
I think a mistake.
Speaker 2 (09:51):
You have to think about what you're.
Speaker 3 (09:52):
Going to do, and certain things are good to have
a UTC. Let's say, timestamps of things happening on your computer,
where you know this happened to this point. For that
UTC is good, but for handling something else. Let's say birthday.
Birthday is not about UTC, it's about sometimes you only
have the information of year, month and date. So a
(10:15):
thing you want to do is look at what information
do I actually have? What data do I actually have
that I know, and to only look at that. So
in that situation, in alix or there's the type date
that has only year, month and date of the month,
and then you don't invent kind of fake data. You know,
some might well might solve this problem by using a
(10:37):
daytime that has like the you know, zero minutes, zero seconds,
point zero zero seconds and so on, and UTC, which
is really just kind of garbage data that you made
up because the library type that you used had this,
and you're kind of forced to do it. Or you
might think, oh, this will simplify things if I basically
(10:57):
use the same type for everything, And in some languages
that's your kind of only option.
Speaker 2 (11:02):
So that was the problem.
Speaker 3 (11:04):
Also, I saw, you know, in JavaScript, for instance, you
have this thing called date, which is really daytime that
has all this extra stuff you don't need find out
what you're actually trying to solve, and choose the correct type,
and don't invent kind of fake data. I think something
related to this is avoid inventing kind of fake extra
(11:26):
data and also at the same time include enough data
that you actually need.
Speaker 2 (11:30):
So another on another.
Speaker 3 (11:32):
Hand, if you do have if you do need to
know something about the time zone, do include the time
zone if you know if you if you don't have it,
you can't magically summon it up later if you haven't
saved it anymore.
Speaker 8 (11:46):
Speaking kind of invalid bogus data, one of the things
that I took away from your talk was entering twenty
three dogs in Ruby and having it actually come out
as a valid date.
Speaker 9 (11:56):
Did you ever figure out like why that happened.
Speaker 3 (11:58):
Yeah, soul Strucipim actually sent me a link to that
or told me about it, and there's some place in
a stag overflow where they talk about it where you
can google that as an example. I'm not sure. I'm
not sure exactly why it is. I didn't want to
look too much into it, but what it got from
(12:18):
that is it's an example of trying to be too
permissive in parsing. That's another thing that I think Elixir
is good at. And this whole fail first and fail early.
I think that those ideas gel well with Elixer. And
that's also something I think is important is if there's
(12:39):
some information and data you need, you need to have it,
and it's a good thing to throw an error if
it's not there instead of inventing something fake.
Speaker 5 (12:47):
Yeah, I think that goes nice so long with a
kind of the spirit of the language where everything is
more German towards explicitness versus implicitness. So the language will
definitely try to put up some guardrails that maybe things
aren't being misinterpreted or messed around with in a way
that's kind of undefined to the user. So I definitely
definitely appreciate that. To kind of piggyback off of the
(13:09):
previous question. When it comes time to persist the daytime
information to your database you kind of hinted at before,
you know, don't just naively make everything UTC if it
doesn't apply. Kind of what are some best practices around that?
You know, I historically have just been throwing everything as
UTC and just taking care of it on the presentation layer.
So have I been doing it wrong? Should I be
(13:31):
you chastised publicly here for that? You know, it really
depends on what you're doing. So in some cases that
is the correct approach, although I would say this whole
you know, this kind of sounds like what a lot
of people recommend. They're saying everything should be you to
see daytimes and then in a presentation layer you can
(13:53):
change it. But I think that's dangerous because a lot
of times the dates you tell someone on that visits
your website or uses your system can be very important.
So let's say you have some kind of contract or
order or something and there's some deadline or some date
that is very important. If you just say in UTC's
(14:16):
this date and then you just put it somewhere else
in presentation l or you don't care so much about it,
that can change, you know, from one day to the other.
And that I would say is business logic. What you
tell your customer in this case is business logic, and
it's something you want to know about. So, you know,
let's say there's a time for a meeting. You probably
want to save the time. Let's say you say, oh,
(14:38):
this is in a Pacific time at eight o'clock in
the morning. Let's say that might be how you define it.
So you would save eight o'clock in Pacific time somehow.
One way to do that is the Ayana time zone
names for instance America slash Los Angeles. One of the
reasons is that if you have something in the future,
(15:00):
first of all, you will know it's more closely fu
to what you actually want to know and want to save.
And also if if it's far enough in the future
that the time zone sound sorry, if it's far enough
in the future that the time zone rules change, you
can actually recalculate that, and you can you will know
(15:20):
what your original intention was. And this has been a
problem in practice in certain cases where where people have
where the rules have changed. So basically, yeah, save the
you can save the eight daytime plus the time zone name.
Speaker 2 (15:35):
I also have on.
Speaker 3 (15:36):
My blog Creative deletion dot com there's a blog post
about why UTC is not the correct approach for saving
future day times. So for when it comes to saving
things in UTC, I think that can be great if
that is what you want to say. And I think
if the general approach is just make sure you save
(15:57):
what you need to save, like kind of the debase data,
if that makes sense, instead of something you want to
pre calculate for the future. If you want to do that,
you can do that also, but don't throw away kind
of the basic data that that really matters. Right, So
to explain that a bit more, this example, it would be,
let's say a meeting in specific time you want to save,
(16:20):
like the local time, and that is the time zone
name for the Pacific time, and then you could pre
calculate what would that be u to see if you
wanted to need that for performance reasons something. Save what
you really need for the future.
Speaker 5 (16:34):
Yeah, I mean, I definitely that it makes sense. And
then if you ever need to let's say that meeting
wasn't Pacific time because that's where maybe the meeting organizer is.
And in our remote world nowadays with COVID, let's say
I'm in a different time zone and I need to
go to that meeting, but I want it locally. You
could still do that kind of a time zone conversion,
(16:54):
but you still have that initial piece of meta data
that hey, the organizer was in this time zone, this
was the origin time for that time zone.
Speaker 2 (17:01):
So that's that's a cool tip.
Speaker 4 (17:03):
I like it, And I also like the idea that
if you had something like you know, labor day that
is September, you know whatever, right, and to not try
to attach time zone data to that, and not try
to attach time data at all.
Speaker 2 (17:20):
I like that.
Speaker 4 (17:21):
You know at that point you want to be a naive,
you know, you don't you don't need to map it
to a time zone or or a time exactly.
Speaker 3 (17:28):
Yeah, because sometimes that extra data can come back to
hurt you because libraries or other systems will want to
interpret that and sometimes they will say, oh, this is
in uh, you know, in in the US, it might
be one day and then and you to see it's
actually the next day if it's like the evening in
(17:49):
someplace in the US and US see it could be
actually the next day. And then you have this idea
of the presentation layer just throwing away all the other
stuff and then you're left with just a simple date,
but it's the wrong one. So this also, I think
is important when communicating with other systems when you have APIs,
you know, to communicate all the necessary data but not
sort of extra extra stuff.
Speaker 4 (18:10):
Is someone who might or might not have been me
actually gave gave employees the wrong day off that causing
a big hull of blue might or might not have
been me.
Speaker 5 (18:20):
When it comes time to write tests for all this
daytime goodness, given that's a impeer operation, right.
Speaker 2 (18:28):
You know UTC now is.
Speaker 5 (18:29):
An impeer operation because it's depending on the clock.
Speaker 1 (18:32):
Right.
Speaker 5 (18:33):
All kind of patterns or suggestions you have for people
to write kind of deterministic tests around times. Do you
create mocks or you can control the clock? Do you
provide most of your functions with the time as like
a param so that those functions remain pure? You know,
what are the kind of the patterns that you followed
to ensure that your tests don't fail randomly and they're
(18:53):
off by like a second.
Speaker 3 (18:54):
One interesting thing about the function in the standard library
is that most of the functions are pure except for
you to see now, as you mentioned. And there are
also some other functions that get now, but they're kind
of a version of UTC now, you could say.
Speaker 2 (19:12):
So what you can do is you can.
Speaker 3 (19:14):
Pass in now as a as an argument that has
a default argument of you to see now. That's one
way to do it, and another way is also, like
you mentioned, having some kind of mock. You can have
a you could have some kind of adapter. Let's say
you have a time adapter and then in your code
you call that. And then in your test code you
(19:36):
can have a configuration where you have the real time
adapter and your test time adapter. So in your code
you call whatever adaptor it is, and you have the configuration,
switch out the real time adaptor for a test one.
Then you can you can decide what time it is
with that one. So those are some ways of doing it.
Speaker 4 (19:56):
It kind of strikes me that in the testing area,
this is time problems are look to me like a
symptom like we haven't gotten our testing models right yet.
So this this strikes me as one area where property
based testing will be a huge, huge boom, right because
then you're talking about the properties based on when something
(20:19):
was created and when something was compared and those kinds
of things. It's just a hint to me that we
don't have not just Alixer, but the greater software industry.
We don't have the right abstractions for tests yet.
Speaker 3 (20:34):
What do you think, Yeah, I think so what I
mentioned before with UTC, now that's I guess only. Well,
first of all, I think, yeah, it's it's I think
you're right that it's it's an interesting problem to something
that isn't solved. I would also say that it's for
just UTC now. I think that what I just mentioned
(20:54):
is one solution, and it can solve a lot of things.
But beyond just UTC now and making sure you have
just some pre defined tests where you just look at
you say, okay, I'm going to decide instead of probably
based testing, you have some examples, I can decide, I'm
going to test these few things. Beyond that, one interesting
(21:16):
thing about DAYNA and time, for instance, is edged cases
that you might not think about, such as daylight saving
time and uh leap seconds also leap years. Right, So
you if you just come up with these examples yourself,
(21:36):
maybe you just make a few examples at work and
and the you know, the tests are green, and then
you're you think that's great, and you're you ship it.
Speaker 2 (21:43):
And then you it doesn't happen. And you could do this, let's.
Speaker 3 (21:46):
Say in a in a long leap year, and then
it's only three years later that someone will find out
that you had a bug in your code that only
shows up a leap year. So I think it's it's
uh a problem that's interesting because of these things, you know,
you're not just dealing with simple problems, but things that
(22:07):
can change over time. And that's also something that's difficult
with the whole idea of thinking about time zones and
you're handling that is not only do you know time
passes and things happen all the time like with every
other program, but also the rules can change, so you
kind of have to think of on different levels of
that thinking about testing. Besides what we talked about before
(22:29):
with how do you you know in your test fix
what the time is right now? I think it's useful
to test around things where you switch from summer to
wintertime or daylight saving time. If you make tests just
around those times, that can be useful. So if you
don't have some framework where they you know, it can
(22:50):
think of everything for you, which, by the way, I'm
not sure how easy that would be to do. You
probably should think about these things and test them. I
guess this is the thing about dealing with data and time.
It's something that sometimes people think, oh, a library should
just fix everything for me, But in some cases it's
just it is a part of the real world and
you can't always just ignore it, like it is your
(23:14):
responsibility to some extent, and you have to think about it.
Speaker 2 (23:17):
So for testing, yeah, test.
Speaker 3 (23:20):
Around those those kind of edge cases, if you can
think of them, that's what I would recommend.
Speaker 4 (23:24):
Yeah, we're just twenty short years from like a massive
edge case sweeping through the whole industry, right, the White
two K. I don't know if any of you youngsters
are or can remember any of that that I remember
that planes were going to fall out of the sky
and reactors we're going to melt down. And yeah, but
(23:46):
for some brilliant work with you know, the Cobol window algorithm,
some of that might have come to pass.
Speaker 3 (23:53):
Yeah, there's also the when is it why? Twenty thirty
eight problem? Right, that will come up, So let's see
how that's.
Speaker 2 (24:02):
Going to pass.
Speaker 1 (24:03):
Speaking of you know, you mentioned like, well, what would
you expect a library to handle or you know, people
want libraries to handle everything for you. So speaking of libraries,
you are actually the creator of tz data. So I
was wondering if you could tell us a little bit
more about that library and kind of it's relationship or
how you might use it with some of the Elixir
(24:24):
core library time and daytime functionality. Since I know you
have a blog post that came out a couple months
ago saying you might not need the calendar or time
x library, so what library should we reach for? Where
does tz data fall in all of this? And yeah,
if you want to share some of your thoughts around.
Speaker 2 (24:41):
That, sure.
Speaker 3 (24:42):
Going back to twenty fourteen, I started working on this
library where there was both the time zone handling and
these new types of daytime, date and time and eight daytime.
And then later t set data was extracted from. So
that means that that library that was first called calend,
(25:05):
later Calendar was now calendar that dependent on t set
data and also time makes dependent on t set data.
Then a little while later a lot of so these
types from Calendar were now available in almost the same
form in the sendate library. So now in the standard
library we have dat time, daytime and daytime. And at
(25:28):
first you could not do time zone operations just directly
from the standard library. So what happened in version one
point eight was re introduced this behavior for a time
zone database, which means you can in alix er configure
it to use a certain times on database. And tseet
data is right now the most popular one or the
(25:52):
first one, but there are alternatives. As far as I know,
and there can be alternatives, new ones coming up in
the future. But what you can do is you can
if you use Elisa one point eight or later, you
can go in and configure t set data or you
can pass in that module name to every function you
(26:13):
call inder stand the library that needs this. But the
easiest versions just good to configure it, and then you
can actually call functions like daytime dot now and passing
a time zone name, Elisa will call the t set
data library and do all the necessary calculations.
Speaker 2 (26:32):
So this means that there's a.
Speaker 3 (26:33):
Lot of things that you would have needed libraries such
as calendar or time mix to do before in order
to do these calculations. By calling tset data now instead,
you can call these function instand the library. Provided you
have a time zone database library. You could even write
(26:55):
your own time data database library if you want to
see because there's this behavior, so I think that that's
a great thing that there is, you know, a defined
interface for that in that this time some database behavior.
Speaker 1 (27:08):
I think that's so cool the way you put that,
Like you can use the Elixir standard library to use
t Z data to do time zone calculations. And first
of all, that's just incredible. And what was developing, you know,
towards this goal, Like did you work with other Elixir
core contributors to kind of figure out this partnership and
(27:29):
this API? Did this just kind of like magically come together?
What was working on this?
Speaker 3 (27:34):
Like, first, I, you know, when developed the counter library,
it was mostly on my own and I did this
presentation at Alexicon twenty fifteen. And there was also this
splitting of the TSET data library, which was as far
as remember, Civilian basically asked me, Oh, wouldn't it be
(27:56):
a good idea if you split this out?
Speaker 2 (27:58):
And then also and also that time as could use this.
Speaker 3 (28:02):
And then later for ALIXA one point three, Shusivilian asked
me and Paul Joan Fielder for input for getting some
of this, basically getting the types into the standard library.
So that meant that you had these types which are daytime, daytime,
LYAD daytime, and they would be common for the calendar
(28:25):
library and TIMEX and also other libraries could use those.
So even if you use different libraries, at least this destructs,
these types would be the same. So then what's happened
since then is that one big thing is that there's
times on database behavior in version one point eight, which
means now you don't use you don't need other libraries
(28:47):
besides at times on database library to do these time
zone calculations. And also they're simply been added a few
more functions to the alix of standid library other things.
And now the next version of the Elixer is going
to have dring formatting of data and time. Also you
can do more and more things with the Stander library,
(29:09):
but you can still use other libraries. And because you
have these common types that are in the stand library,
you have a good way of operating. And you have
this compatibility because you can use those same types. So
you can call one library you get as type back
and you can pass into stand a library. Stand library
does something, gives you a new type back, and you
(29:31):
can pass it to.
Speaker 2 (29:32):
A third library. So it all works together pretty well.
Speaker 1 (29:35):
One of the first things you mentioned when we started
chatting today was that sort of looking around for a
language that got things right when it comes to time
and daytime and time zones is one of the things
that brought you to exploring Elixir. So would you feel
that with especially kind of the recent introductions and Alexa
one to eight of some of this tooling and what's
coming up next? Would you feel like Alixa is a
(29:58):
language that has really gotten this stuff right?
Speaker 3 (30:00):
I would say there is a lot of things that
it's gotten right in my opinion, but also that's I'm
biased since I had a an effect and how how
it looks. But there's there are so many things about
this area that first of all you can only have
you know, you can have libraries that can help you.
But then the next step is also to have people
(30:23):
knowing how to use it. And I think it's it's
an area that is not it's not necessarily super straightforward,
especially if people have been used to doing things in
a certain way, they might not know what, you know,
what to reach for, how to use it. So that's
that's part of it, you know, and I think it's
in general Elixir is good at you know, it has
(30:44):
good docmmentation. So I'd say, you know, one thing is
how is the language designs what could you potentially do?
And another thing is how do people actually do it?
And how does the language facilitate that with documentations or
error messages or you know, people around language writing blog
posts or or you know, reading something and talking to
(31:06):
other people about it.
Speaker 2 (31:07):
You know, how are people actually using it?
Speaker 3 (31:09):
I guess it's a real success criteria if they if
you know, if people are able to use this language
in these libraries in a way that solves their problem
in a good way. And I think there's a lot
of there's still a lot of ongoing development, and there
are more people working on it right now, and there's
(31:30):
more things coming. I think a lot of the basics there.
I think there are just a few basic things that
I think are good that we have, such as the
these different types where for instance, in if you have
a date, it's called a date and it's not actually
a daytime, and that maps.
Speaker 2 (31:48):
Well too with ECTO.
Speaker 3 (31:50):
So another thing is also you know, Ecto started supporting
these vender types, so you can you can save a
date and you can put it into the data base
and it comes back again and it's just a date.
Ecto didn't add a minute that was zero, in the
second that was zero, and all that stuff.
Speaker 2 (32:08):
You even have.
Speaker 3 (32:09):
You know, you have to use sex or microsecond versions
and the non micro second versions for Ecto, so you
can even say I want to actually save my million
seconds for microseconds, and it won't depending on what you
choose there for your type, it won't like add to microseconds.
You have you have to like look at that and
get that right, but you have the availability to do that,
and the same thing with the other types. So I
(32:31):
think there's a there's a lot of potential too and
possibilities to get things right, but you need each programer
has a certain responsibility to kind of look into it
a little bit. And also I'm sure there's still more
work to do to to tell people about how we
can use these libraries. Yeah, that's it's something I hope
(32:53):
to to uh, you know, help with also in the
writing blog posts and uh answering questions and and that
there are other.
Speaker 2 (33:01):
People in that too.
Speaker 3 (33:02):
So yeah, I think basically it's pretty good, but it's
a difficult.
Speaker 2 (33:06):
Problem and there's a lot more to do.
Speaker 4 (33:09):
So I really love this story, especially from a couple
of perspectives. I love the idea that this is a
project that kind of started on its own, but you
worked with the highest elements of language. When it became
clear that these worst ideas that we wanted to fold
in not just from the standard library but also from
ECTO and things like that, it's really cool to me.
The second thing I love your understanding that maybe you
(33:32):
can't get everything right or perfect right is it's almost
like you can only try to mitigate the damage because
there's so much is there so many complex, complex land
mines around this area. But you can mitigate the damage
by not stopping at the boundaries of the code, right.
You have to push into documentation, into education, into into
(33:57):
blog posts, into stack overflow, all these places that that
we kind of see a particular message that's really vital
to get as clocus as close as you can and
push those ideas in. So from kind of the way
the time libraries are carved up to the way that
(34:17):
you've kind of taken an increased leadership role in the language,
I think it's really cool.
Speaker 5 (34:23):
Yeah, I think it helps a lot that we have
great developer experience tools like you know, uh xtoc and
hex stocks. As library maintainers, you try really really hard
to make sure that your documentation.
Speaker 2 (34:35):
Is super clear.
Speaker 5 (34:36):
You try to include as many examples as possible, and
uh it's kind of like a point of pride if
your if your hex stocks page looks you know, super
clean and and you don't have to turn to stack
overflow for questions because you can just look at the
docs and you're you're all your questions are answered right there.
So I definitely feel that that's something that the Electric
community has gotten right, is focusing on tooling so that
(34:58):
people can be self sufficient and teach themselves.
Speaker 8 (35:01):
I agree that a whole having the documentation generator in
with the language makes it so much easier when you're
writing libraries because you're not searching for like how do
I get docs into this, so as a response, you
can pretty much have good documentation all the libraries, which
is really nice. Speaking of kind of other libraries, is
there any other projects that you're contributing to right now?
Speaker 3 (35:20):
Right now, I'm not working as much a OVID source
as I used to before. I would contribute to t
set data, cander that I made, and also elix to itself,
Ecto Phoenix, trying to mostly trying to push some of
these data and time things into it, and in some
cases also some other details. But yeah, I'm still maintaining
(35:44):
t set data and that's kind of the main thing
right now.
Speaker 8 (35:47):
I have to say, I'm very thankful for your work
because I've used it quite a bit. Throughout the years,
every time I've been dealing with day and time, especially
before daytime, and now you've daytime made it into the
Standard library. It was always a bit more difficult before,
but now it's it's just a natural piece of the language.
Speaker 9 (36:04):
It's so simple, So I thank you for that.
Speaker 5 (36:06):
Sure, yeah, I definitely want to echo that. I mean,
looking at X right now, tz data is almost the
twenty almost twenty four million downods of all times. I
think everyone here definitely appreciates the work you put into it,
and plenty of people around the world, So thanks well.
Speaker 1 (36:21):
On that note, I think this is a great time
to transition into picks and what we'll do is we'll
just kind of round robin and if anybody has any recommendation,
suggestions or links that they'd like to share, and now's
the time. I'm going to go first, and I'm going
to pick a blog post from back in May from
Yu Lao on calendar and TIMEX and the Elixir Standard
(36:45):
Library's expansion of dealing with a lot of these date,
day time, time zone capabilities. I thought it was a
really nice introduction to the topic. It was a really
nice kind of call for using these tools and libraries
the right way and at the right time, and definitely
appreciated you putting it out and doing some of this
really really critical education work on top of all of
(37:05):
the open source contributions that you've given us in this area.
So would love for some of our listeners to check
that out. And with that, I will hand over our
picks to Bruce.
Speaker 2 (37:15):
Yeah, I've got a couple.
Speaker 4 (37:17):
Of course, as Garatio as a sponsor, there's always a
Grozio pick, so I'll start there, So the Grazio pick.
I just finished the recording session with Brian Trottwine for
a short video series called Why Things Fail And for
those of you who don't know, and Brian is a
marvelous storyteller and failure expert expert, so he's done talks
(37:42):
on from everything to turnobyl to This particular series is
starting with one called the Boston Molasses Flood and there's
a great book on that called Dark Tide. So subscribe
to a video channel YouTube dot com slash c slash groxio.
The one is every time that I would try to
(38:03):
do some datemath and actually try to sneak it into
our code base, James Gray would find it and he
would respond with always with just a single link. And
this is a famous YouTube video called the Problem with
Time and time Zones with an excellent video video author
(38:25):
called computer File tremendous series. This one has I don't know,
a couple million downloads or something like that, so check
it out.
Speaker 9 (38:33):
Wonderful.
Speaker 1 (38:33):
Thanks Bruce. And how about Eli and.
Speaker 9 (38:35):
He picks for us?
Speaker 3 (38:36):
First of all, where I work at three Real, we
are hiring, so if you're interested in working with the lakser,
let me know. Another pick is this book that I like,
if not for anything else, that mentions having units of
measure when you program things. So it's domin Modeling made
(38:58):
Functional by Scott Collection, and it talks about the main
modeling and uses f sharp as an example. And I
think it's interesting to at least read through and it
can give you an example of how to do that
in functional language. So I think that maps well to Elixir.
(39:21):
And yeah, like I said, the one thing that especially
is relevant also to to this, even though it's a
small detail, is how you it's important to save little
details such as unit of measure like you have instead
of having a monitor rally being an integer of one,
you have the USD or c a d in stuff.
(39:45):
In addition to that it is an important detail then
can mean your data.
Speaker 2 (39:51):
Is useful or useless. And also in general, my blog
is creative deletion a calm. That's it.
Speaker 1 (40:01):
Awesome, Thank you. Yeah, I've been enjoying checking out your
blog lately, so definitely echo that recommendation. Any picks from.
Speaker 9 (40:08):
Unique up, I actually don't have any picks today, fortunately.
Speaker 1 (40:11):
Okay, you'll just owusun for next time, Alex, anything from you.
Speaker 5 (40:16):
Yeah, sure. So I got two Elixir related picks for today.
So the first one is a blog post by I
Guess Dasky on dev dot two. It's called an IoT
Birdhouse with Elixir nerves and Phoenix live components. So I
found out to be a pretty cool article kind of
spanning from you know, the web and hardware and tying
(40:36):
it all together. So I think that was a really cool,
really cool read. My next pick is a blog post
that I wrote my blog, and it's called dynamically Configure
your plugs at runtime, and I outline kind of the
problems I was having with dynamically executing plugs or configuring
them at run time, and I wrote two libraries, one
called Unplugged, which I was surprised to get that hex
(41:00):
package name, and one called replug and uh, you know,
those kind of solve problems that I was having, and
I'm sure that other people have had similar issues. So
I put my learnings up on the blog and hopefully
people find those two as useful.
Speaker 1 (41:13):
I'm definitely gonna check out that last one because yeah,
not a stranger to that problem.
Speaker 9 (41:18):
All right.
Speaker 1 (41:19):
I think that's it for today's episode. Thank you so
much for joining us. Thank you to our guests Lal
and hopefully we'll have a chance to talk with you
again in the future. And the shout out for upcoming
Alixir KOMPF. I think this episode will air before then.
If not, then of course you all are very confused.
But if it does air before, Alexa Kromp, you haven't
gotten your ticket yet, it's all the time, all right.
Speaker 9 (41:39):
Thanks everybody, Thank you, Thanks everyone. Thanks
So hello and welcome to today's episode of Alixir Mix. Today,
our fabulous panel of hosts includes Bruce Tae Pre Elixir
comp Greetings everybody, Oh yeah, happy, Kreo Alixakov greetings, nice one.
We also are joined by Lars Vikmam Hey Lars. We've
got Mika Khalafiel, Hey everyone, and Alex kutmoas Hey Alex.
(00:29):
And we are joined today by a very professional guest,
Llow Tornsco. Thank you for joining us. Laud and Law
as an engineer at the Real Reel and he's been
doing some writing lately and some speaking on the topic
of daytime in Elixir, everybody's favorite or perhaps most dreaded
topic often in any programming language, date and time. But
(00:50):
before we get into some of the questions that we
have for you, love, if you want to maybe go
ahead and tell us a little bit about yourself and
what brought you into the Elixir community.
Speaker 2 (00:59):
Hello. Yeah, I'm happy to be here on the show.
Speaker 3 (01:02):
So I started doing Alixir around twenty fourteen, and I've
been using different program.
Speaker 2 (01:10):
Languages before that, a lot of Ruby before Elixir.
Speaker 3 (01:14):
One of the things I started looking at was there
was no solution for time zones, and I had previously
had some issues with how data and time.
Speaker 2 (01:23):
Was handled in other languages.
Speaker 3 (01:26):
So I thought, and I thought, this was a new language,
how could I make this more enjoyable to work with
in this new language? Because I saw myself working with
the elixer for a long time, so that was something
I thought that was a problem for me and probably
also for other people. So that's one of the things
I started looking at. And then I've been doing Elixir
(01:50):
ever since, both open soores and working with the professional So.
Speaker 4 (01:55):
Everybody has their little Elixir moment the top that you
kind of looked at the language and uh, hey, that's
that's cool or interesting. I want to know a little
bit more about that. What was your first program or
the first thing that you saw where you think where
you thought this language has a chance to be pretty
cool for me.
Speaker 2 (02:11):
Yeah, now I'm just thinking back. Yeah.
Speaker 3 (02:14):
The funny thing is the the first real library I
wrote was this time zone handling. So yeah, if you
if you look back at the at the code, that
was like.
Speaker 2 (02:23):
Me learning and exerting that and that was the first one.
Speaker 3 (02:27):
I mean, there was there was a little world, but
that was kind of for first real project. The thing
basically I thought I had when I first started using Ruby.
I that was around the time, that was before Rails
was released, and I saw kind of the beginnings of
Rails was one of the reasons I started using Ruby,
and I thought, this is going to be super popular. This,
(02:51):
this is so much better than pH P or Java,
that was another solution for the web before, and there
was different other languages coming along, and I've been of
the mindset that I didn't really want to switch languages
all the time unless something was like ten times better,
because or if something is twenty percent better, it can
(03:15):
be cool to learn it to learn different things. I'm sure, Bruce,
you're all about, you know, learning new learning, learning new
languages and learning new things from that one language. But
this was the language that was I thought was so
much better. Basically it could do. I thought you could
do everything you would want to do with Ruby. You
could do and you could do better with Alixir, just
(03:36):
just in terms of how how simple it is to
understand the programs you write with it. I guess big
thing with it is how it's immutable and how you
can reason about it. So when you have arguments coming in,
you know what you have there you can reason about it,
whereas in Ruby and other object during languages, you have
(03:57):
something and there's a lot of times the groovy dot
dup to make sure no one's knowing nothing else is
messing with what data you have there. So I thought
the functional nature of Elikser was great, and I guess
it felt like something I've been looking for for a
long time and didn't realize it. And then on top
of that, you have, you know, there's so many things
(04:19):
coming together. So on top of that, you have the
concurrency aspect of it, and how it just made sense
with the web and concurrency, and how it was made
for telephone networks that map so well to the Web,
and you have you know, web clients instead of telephones.
And yeah, there's just so many things that made sense
(04:41):
to me.
Speaker 2 (04:41):
So it's hard. It wasn't one thing, it was many
things together.
Speaker 4 (04:46):
That might be the most thoughtful answer I've ever heard
of that question.
Speaker 5 (04:49):
Yeah, I kept a lot and interrupt and be like yes, yes, yes,
yes to all those points and more. I definitely, I
definitely echo all those all those sentiments.
Speaker 2 (04:58):
I mean, from the fact that.
Speaker 5 (04:59):
It's a functional language, but it's a very pragmatic functional language.
Josh Adams isn't with us today, so I can bag
on Haskell a little bit. But yeah, I mean I've
tried Haskell in the past. I always found it a
little too verbose, too difficult to reason about. Again, maybe
it's just not my cup of tea, but I did find,
you know, a lick sort of be a very pragmatic
(05:20):
functional language. And I think camera where I heard it from.
But I think one of the Airline initial designers said
that they made it functional from a like a use
case perspective, not necessarily they sought out to make a
functional language from an academic perspective. They wanted to make
a functional language, or they want to make a language
that could deal with a problem, and functional programming paradigms
(05:40):
kind of helped solve that problem. So it's a very
pragmatic road to that solution that drives with me, and
I think that's why I've stuck around. Yeah, you see
all the heads of everybody kind of nodding. I know
that this is kind of an audio podcast, but yeah,
that's that's kind of cool. And one of the things
that that struck me about that answer is that he
jumped into a new language and said, hey, I'm going
(06:03):
to solve a problem that I recognized in the language
in the language, which is interesting to me because it
takes a lot to recognize as a newcomer where the
weak points are in a language right off the bat,
I don't know that I could do something like that.
Speaker 6 (06:20):
And also just the fact that starting out and going
right for times, dates and basically all the complexity that
most developers absolutely will use the library to avoid and
just like, yeah, i'll work with that.
Speaker 7 (06:38):
Can unpack how that decision making happens, because I don't
quite grasp how you would approach a new language and
decide that that's what you're doing.
Speaker 2 (06:49):
It's impressive.
Speaker 3 (06:51):
Yeah, I think it's because I had so many problems
with how it was handled in other places, so I thought,
at least to begin with, I wanted to think it
came at the same time, At one hand, I wanted
to explore what this problem is generally regardless like of
(07:12):
regardless of the language, like how how is how is
state and time handled? How should it be handled? And
then specifically for Elixir, I wanted to implement some solutions
for that. So I got it was partly being interested
in the subject because it was such a thing. It
was a thing like you say that some people dread
(07:36):
or don't like, but everyone will use it and you
will have to use it. So I thought, this is
something interesting too to look at. How would how would
I want it to be solved? And then I just
started studying it a lot and just kept working on it.
Speaker 2 (07:54):
And also I should mention.
Speaker 3 (07:56):
That now today, many years later, there's a lot more
people working on it. There were also people working on it, uh,
you know, a few people work on it in the beginning,
and and now even more so.
Speaker 2 (08:08):
So that's great to see.
Speaker 3 (08:10):
I thought it was interesting and it's been rewarding and
and and yeah, I thought it was an interesting problem
to solve.
Speaker 4 (08:17):
So I had a coworker's name was James Gray, and
he so a smile on God from LARSA. Yeah, a
good friend of mine, and wrote the book Designing Elixer
Systems with OTP or I guess I wrote it with him,
would be the right way to say that, right, But
but James always said when whenever any one of us
ever dropped a line into the code that did date math,
(08:39):
he would say, no, no, no, there there there are
some problems that you don't try to solve at hoc.
We need libraries. What are some of the common mistakes
that you've seen people make when they try to do
their own roll, their own ad hoc date math.
Speaker 3 (08:57):
I think an important part of this that also so
to step back a bit. The important part of this,
I think is to first think about what you're trying
to achieve. So, for instance, sometimes if you have an
example of a birthday and then you want to calculate
something related to dates, One thing that I thought was
(09:20):
annoying or confusing was how people use the word date
to mean something else than just to date, so you
can have like first, you know, people might say a
common thing that programmers will say sometimes is convert everything
to UTC, and then they will also talk about dates,
and they will have seconds and minacent them and time
(09:42):
zones all of a sudden because it's UTC. So the
thing about converting everything to UTC, first of all, that's
I think a mistake.
Speaker 2 (09:51):
You have to think about what you're.
Speaker 3 (09:52):
Going to do, and certain things are good to have
a UTC. Let's say, timestamps of things happening on your computer,
where you know this happened to this point. For that
UTC is good, but for handling something else. Let's say birthday.
Birthday is not about UTC, it's about sometimes you only
have the information of year, month and date. So a
(10:15):
thing you want to do is look at what information
do I actually have? What data do I actually have
that I know, and to only look at that. So
in that situation, in alix or there's the type date
that has only year, month and date of the month,
and then you don't invent kind of fake data. You know,
some might well might solve this problem by using a
(10:37):
daytime that has like the you know, zero minutes, zero seconds,
point zero zero seconds and so on, and UTC, which
is really just kind of garbage data that you made
up because the library type that you used had this,
and you're kind of forced to do it. Or you
might think, oh, this will simplify things if I basically
(10:57):
use the same type for everything, And in some languages
that's your kind of only option.
Speaker 2 (11:02):
So that was the problem.
Speaker 3 (11:04):
Also, I saw, you know, in JavaScript, for instance, you
have this thing called date, which is really daytime that
has all this extra stuff you don't need find out
what you're actually trying to solve, and choose the correct type,
and don't invent kind of fake data. I think something
related to this is avoid inventing kind of fake extra
(11:26):
data and also at the same time include enough data
that you actually need.
Speaker 2 (11:30):
So another on another.
Speaker 3 (11:32):
Hand, if you do have if you do need to
know something about the time zone, do include the time
zone if you know if you if you don't have it,
you can't magically summon it up later if you haven't
saved it anymore.
Speaker 8 (11:46):
Speaking kind of invalid bogus data, one of the things
that I took away from your talk was entering twenty
three dogs in Ruby and having it actually come out
as a valid date.
Speaker 9 (11:56):
Did you ever figure out like why that happened.
Speaker 3 (11:58):
Yeah, soul Strucipim actually sent me a link to that
or told me about it, and there's some place in
a stag overflow where they talk about it where you
can google that as an example. I'm not sure. I'm
not sure exactly why it is. I didn't want to
look too much into it, but what it got from
(12:18):
that is it's an example of trying to be too
permissive in parsing. That's another thing that I think Elixir
is good at. And this whole fail first and fail early.
I think that those ideas gel well with Elixer. And
that's also something I think is important is if there's
(12:39):
some information and data you need, you need to have it,
and it's a good thing to throw an error if
it's not there instead of inventing something fake.
Speaker 5 (12:47):
Yeah, I think that goes nice so long with a
kind of the spirit of the language where everything is
more German towards explicitness versus implicitness. So the language will
definitely try to put up some guardrails that maybe things
aren't being misinterpreted or messed around with in a way
that's kind of undefined to the user. So I definitely
definitely appreciate that. To kind of piggyback off of the
(13:09):
previous question. When it comes time to persist the daytime
information to your database you kind of hinted at before,
you know, don't just naively make everything UTC if it
doesn't apply. Kind of what are some best practices around that?
You know, I historically have just been throwing everything as
UTC and just taking care of it on the presentation layer.
So have I been doing it wrong? Should I be
(13:31):
you chastised publicly here for that? You know, it really
depends on what you're doing. So in some cases that
is the correct approach, although I would say this whole
you know, this kind of sounds like what a lot
of people recommend. They're saying everything should be you to
see daytimes and then in a presentation layer you can
(13:53):
change it. But I think that's dangerous because a lot
of times the dates you tell someone on that visits
your website or uses your system can be very important.
So let's say you have some kind of contract or
order or something and there's some deadline or some date
that is very important. If you just say in UTC's
(14:16):
this date and then you just put it somewhere else
in presentation l or you don't care so much about it,
that can change, you know, from one day to the other.
And that I would say is business logic. What you
tell your customer in this case is business logic, and
it's something you want to know about. So, you know,
let's say there's a time for a meeting. You probably
want to save the time. Let's say you say, oh,
(14:38):
this is in a Pacific time at eight o'clock in
the morning. Let's say that might be how you define it.
So you would save eight o'clock in Pacific time somehow.
One way to do that is the Ayana time zone
names for instance America slash Los Angeles. One of the
reasons is that if you have something in the future,
(15:00):
first of all, you will know it's more closely fu
to what you actually want to know and want to save.
And also if if it's far enough in the future
that the time zone sound sorry, if it's far enough
in the future that the time zone rules change, you
can actually recalculate that, and you can you will know
(15:20):
what your original intention was. And this has been a
problem in practice in certain cases where where people have
where the rules have changed. So basically, yeah, save the
you can save the eight daytime plus the time zone name.
Speaker 2 (15:35):
I also have on.
Speaker 3 (15:36):
My blog Creative deletion dot com there's a blog post
about why UTC is not the correct approach for saving
future day times. So for when it comes to saving
things in UTC, I think that can be great if
that is what you want to say. And I think
if the general approach is just make sure you save
(15:57):
what you need to save, like kind of the debase data,
if that makes sense, instead of something you want to
pre calculate for the future. If you want to do that,
you can do that also, but don't throw away kind
of the basic data that that really matters. Right, So
to explain that a bit more, this example, it would be,
let's say a meeting in specific time you want to save,
(16:20):
like the local time, and that is the time zone
name for the Pacific time, and then you could pre
calculate what would that be u to see if you
wanted to need that for performance reasons something. Save what
you really need for the future.
Speaker 5 (16:34):
Yeah, I mean, I definitely that it makes sense. And
then if you ever need to let's say that meeting
wasn't Pacific time because that's where maybe the meeting organizer is.
And in our remote world nowadays with COVID, let's say
I'm in a different time zone and I need to
go to that meeting, but I want it locally. You
could still do that kind of a time zone conversion,
(16:54):
but you still have that initial piece of meta data
that hey, the organizer was in this time zone, this
was the origin time for that time zone.
Speaker 2 (17:01):
So that's that's a cool tip.
Speaker 4 (17:03):
I like it, And I also like the idea that
if you had something like you know, labor day that
is September, you know whatever, right, and to not try
to attach time zone data to that, and not try
to attach time data at all.
Speaker 2 (17:20):
I like that.
Speaker 4 (17:21):
You know at that point you want to be a naive,
you know, you don't you don't need to map it
to a time zone or or a time exactly.
Speaker 3 (17:28):
Yeah, because sometimes that extra data can come back to
hurt you because libraries or other systems will want to
interpret that and sometimes they will say, oh, this is
in uh, you know, in in the US, it might
be one day and then and you to see it's
actually the next day if it's like the evening in
(17:49):
someplace in the US and US see it could be
actually the next day. And then you have this idea
of the presentation layer just throwing away all the other
stuff and then you're left with just a simple date,
but it's the wrong one. So this also, I think
is important when communicating with other systems when you have APIs,
you know, to communicate all the necessary data but not
sort of extra extra stuff.
Speaker 4 (18:10):
Is someone who might or might not have been me
actually gave gave employees the wrong day off that causing
a big hull of blue might or might not have
been me.
Speaker 5 (18:20):
When it comes time to write tests for all this
daytime goodness, given that's a impeer operation, right.
Speaker 2 (18:28):
You know UTC now is.
Speaker 5 (18:29):
An impeer operation because it's depending on the clock.
Speaker 1 (18:32):
Right.
Speaker 5 (18:33):
All kind of patterns or suggestions you have for people
to write kind of deterministic tests around times. Do you
create mocks or you can control the clock? Do you
provide most of your functions with the time as like
a param so that those functions remain pure? You know,
what are the kind of the patterns that you followed
to ensure that your tests don't fail randomly and they're
(18:53):
off by like a second.
Speaker 3 (18:54):
One interesting thing about the function in the standard library
is that most of the functions are pure except for
you to see now, as you mentioned. And there are
also some other functions that get now, but they're kind
of a version of UTC now, you could say.
Speaker 2 (19:12):
So what you can do is you can.
Speaker 3 (19:14):
Pass in now as a as an argument that has
a default argument of you to see now. That's one
way to do it, and another way is also, like
you mentioned, having some kind of mock. You can have
a you could have some kind of adapter. Let's say
you have a time adapter and then in your code
you call that. And then in your test code you
(19:36):
can have a configuration where you have the real time
adapter and your test time adapter. So in your code
you call whatever adaptor it is, and you have the configuration,
switch out the real time adaptor for a test one.
Then you can you can decide what time it is
with that one. So those are some ways of doing it.
Speaker 4 (19:56):
It kind of strikes me that in the testing area,
this is time problems are look to me like a
symptom like we haven't gotten our testing models right yet.
So this this strikes me as one area where property
based testing will be a huge, huge boom, right because
then you're talking about the properties based on when something
(20:19):
was created and when something was compared and those kinds
of things. It's just a hint to me that we
don't have not just Alixer, but the greater software industry.
We don't have the right abstractions for tests yet.
Speaker 3 (20:34):
What do you think, Yeah, I think so what I
mentioned before with UTC, now that's I guess only. Well,
first of all, I think, yeah, it's it's I think
you're right that it's it's an interesting problem to something
that isn't solved. I would also say that it's for
just UTC now. I think that what I just mentioned
(20:54):
is one solution, and it can solve a lot of things.
But beyond just UTC now and making sure you have
just some pre defined tests where you just look at
you say, okay, I'm going to decide instead of probably
based testing, you have some examples, I can decide, I'm
going to test these few things. Beyond that, one interesting
(21:16):
thing about DAYNA and time, for instance, is edged cases
that you might not think about, such as daylight saving
time and uh leap seconds also leap years. Right, So
you if you just come up with these examples yourself,
(21:36):
maybe you just make a few examples at work and
and the you know, the tests are green, and then
you're you think that's great, and you're you ship it.
Speaker 2 (21:43):
And then you it doesn't happen. And you could do this, let's.
Speaker 3 (21:46):
Say in a in a long leap year, and then
it's only three years later that someone will find out
that you had a bug in your code that only
shows up a leap year. So I think it's it's
uh a problem that's interesting because of these things, you know,
you're not just dealing with simple problems, but things that
(22:07):
can change over time. And that's also something that's difficult
with the whole idea of thinking about time zones and
you're handling that is not only do you know time
passes and things happen all the time like with every
other program, but also the rules can change, so you
kind of have to think of on different levels of
that thinking about testing. Besides what we talked about before
(22:29):
with how do you you know in your test fix
what the time is right now? I think it's useful
to test around things where you switch from summer to
wintertime or daylight saving time. If you make tests just
around those times, that can be useful. So if you
don't have some framework where they you know, it can
(22:50):
think of everything for you, which, by the way, I'm
not sure how easy that would be to do. You
probably should think about these things and test them. I
guess this is the thing about dealing with data and time.
It's something that sometimes people think, oh, a library should
just fix everything for me, But in some cases it's
just it is a part of the real world and
you can't always just ignore it, like it is your
(23:14):
responsibility to some extent, and you have to think about it.
Speaker 2 (23:17):
So for testing, yeah, test.
Speaker 3 (23:20):
Around those those kind of edge cases, if you can
think of them, that's what I would recommend.
Speaker 4 (23:24):
Yeah, we're just twenty short years from like a massive
edge case sweeping through the whole industry, right, the White
two K. I don't know if any of you youngsters
are or can remember any of that that I remember
that planes were going to fall out of the sky
and reactors we're going to melt down. And yeah, but
(23:46):
for some brilliant work with you know, the Cobol window algorithm,
some of that might have come to pass.
Speaker 3 (23:53):
Yeah, there's also the when is it why? Twenty thirty
eight problem? Right, that will come up, So let's see
how that's.
Speaker 2 (24:02):
Going to pass.
Speaker 1 (24:03):
Speaking of you know, you mentioned like, well, what would
you expect a library to handle or you know, people
want libraries to handle everything for you. So speaking of libraries,
you are actually the creator of tz data. So I
was wondering if you could tell us a little bit
more about that library and kind of it's relationship or
how you might use it with some of the Elixir
(24:24):
core library time and daytime functionality. Since I know you
have a blog post that came out a couple months
ago saying you might not need the calendar or time
x library, so what library should we reach for? Where
does tz data fall in all of this? And yeah,
if you want to share some of your thoughts around.
Speaker 2 (24:41):
That, sure.
Speaker 3 (24:42):
Going back to twenty fourteen, I started working on this
library where there was both the time zone handling and
these new types of daytime, date and time and eight daytime.
And then later t set data was extracted from. So
that means that that library that was first called calend,
(25:05):
later Calendar was now calendar that dependent on t set
data and also time makes dependent on t set data.
Then a little while later a lot of so these
types from Calendar were now available in almost the same
form in the sendate library. So now in the standard
library we have dat time, daytime and daytime. And at
(25:28):
first you could not do time zone operations just directly
from the standard library. So what happened in version one
point eight was re introduced this behavior for a time
zone database, which means you can in alix er configure
it to use a certain times on database. And tseet
data is right now the most popular one or the
(25:52):
first one, but there are alternatives. As far as I know,
and there can be alternatives, new ones coming up in
the future. But what you can do is you can
if you use Elisa one point eight or later, you
can go in and configure t set data or you
can pass in that module name to every function you
(26:13):
call inder stand the library that needs this. But the
easiest versions just good to configure it, and then you
can actually call functions like daytime dot now and passing
a time zone name, Elisa will call the t set
data library and do all the necessary calculations.
Speaker 2 (26:32):
So this means that there's a.
Speaker 3 (26:33):
Lot of things that you would have needed libraries such
as calendar or time mix to do before in order
to do these calculations. By calling tset data now instead,
you can call these function instand the library. Provided you
have a time zone database library. You could even write
(26:55):
your own time data database library if you want to
see because there's this behavior, so I think that that's
a great thing that there is, you know, a defined
interface for that in that this time some database behavior.
Speaker 1 (27:08):
I think that's so cool the way you put that,
Like you can use the Elixir standard library to use
t Z data to do time zone calculations. And first
of all, that's just incredible. And what was developing, you know,
towards this goal, Like did you work with other Elixir
core contributors to kind of figure out this partnership and
(27:29):
this API? Did this just kind of like magically come together?
What was working on this?
Speaker 3 (27:34):
Like, first, I, you know, when developed the counter library,
it was mostly on my own and I did this
presentation at Alexicon twenty fifteen. And there was also this
splitting of the TSET data library, which was as far
as remember, Civilian basically asked me, Oh, wouldn't it be
(27:56):
a good idea if you split this out?
Speaker 2 (27:58):
And then also and also that time as could use this.
Speaker 3 (28:02):
And then later for ALIXA one point three, Shusivilian asked
me and Paul Joan Fielder for input for getting some
of this, basically getting the types into the standard library.
So that meant that you had these types which are daytime, daytime,
LYAD daytime, and they would be common for the calendar
(28:25):
library and TIMEX and also other libraries could use those.
So even if you use different libraries, at least this destructs,
these types would be the same. So then what's happened
since then is that one big thing is that there's
times on database behavior in version one point eight, which
means now you don't use you don't need other libraries
(28:47):
besides at times on database library to do these time
zone calculations. And also they're simply been added a few
more functions to the alix of standid library other things.
And now the next version of the Elixer is going
to have dring formatting of data and time. Also you
can do more and more things with the Stander library,
(29:09):
but you can still use other libraries. And because you
have these common types that are in the stand library,
you have a good way of operating. And you have
this compatibility because you can use those same types. So
you can call one library you get as type back
and you can pass into stand a library. Stand library
does something, gives you a new type back, and you
(29:31):
can pass it to.
Speaker 2 (29:32):
A third library. So it all works together pretty well.
Speaker 1 (29:35):
One of the first things you mentioned when we started
chatting today was that sort of looking around for a
language that got things right when it comes to time
and daytime and time zones is one of the things
that brought you to exploring Elixir. So would you feel
that with especially kind of the recent introductions and Alexa
one to eight of some of this tooling and what's
coming up next? Would you feel like Alixa is a
(29:58):
language that has really gotten this stuff right?
Speaker 3 (30:00):
I would say there is a lot of things that
it's gotten right in my opinion, but also that's I'm
biased since I had a an effect and how how
it looks. But there's there are so many things about
this area that first of all you can only have
you know, you can have libraries that can help you.
But then the next step is also to have people
(30:23):
knowing how to use it. And I think it's it's
an area that is not it's not necessarily super straightforward,
especially if people have been used to doing things in
a certain way, they might not know what, you know,
what to reach for, how to use it. So that's
that's part of it, you know, and I think it's
in general Elixir is good at you know, it has
(30:44):
good docmmentation. So I'd say, you know, one thing is
how is the language designs what could you potentially do?
And another thing is how do people actually do it?
And how does the language facilitate that with documentations or
error messages or you know, people around language writing blog
posts or or you know, reading something and talking to
(31:06):
other people about it.
Speaker 2 (31:07):
You know, how are people actually using it?
Speaker 3 (31:09):
I guess it's a real success criteria if they if
you know, if people are able to use this language
in these libraries in a way that solves their problem
in a good way. And I think there's a lot
of there's still a lot of ongoing development, and there
are more people working on it right now, and there's
(31:30):
more things coming. I think a lot of the basics there.
I think there are just a few basic things that
I think are good that we have, such as the
these different types where for instance, in if you have
a date, it's called a date and it's not actually
a daytime, and that maps.
Speaker 2 (31:48):
Well too with ECTO.
Speaker 3 (31:50):
So another thing is also you know, Ecto started supporting
these vender types, so you can you can save a
date and you can put it into the data base
and it comes back again and it's just a date.
Ecto didn't add a minute that was zero, in the
second that was zero, and all that stuff.
Speaker 2 (32:08):
You even have.
Speaker 3 (32:09):
You know, you have to use sex or microsecond versions
and the non micro second versions for Ecto, so you
can even say I want to actually save my million
seconds for microseconds, and it won't depending on what you
choose there for your type, it won't like add to microseconds.
You have you have to like look at that and
get that right, but you have the availability to do that,
and the same thing with the other types. So I
(32:31):
think there's a there's a lot of potential too and
possibilities to get things right, but you need each programer
has a certain responsibility to kind of look into it
a little bit. And also I'm sure there's still more
work to do to to tell people about how we
can use these libraries. Yeah, that's it's something I hope
(32:53):
to to uh, you know, help with also in the
writing blog posts and uh answering questions and and that
there are other.
Speaker 2 (33:01):
People in that too.
Speaker 3 (33:02):
So yeah, I think basically it's pretty good, but it's
a difficult.
Speaker 2 (33:06):
Problem and there's a lot more to do.
Speaker 4 (33:09):
So I really love this story, especially from a couple
of perspectives. I love the idea that this is a
project that kind of started on its own, but you
worked with the highest elements of language. When it became
clear that these worst ideas that we wanted to fold
in not just from the standard library but also from
ECTO and things like that, it's really cool to me.
The second thing I love your understanding that maybe you
(33:32):
can't get everything right or perfect right is it's almost
like you can only try to mitigate the damage because
there's so much is there so many complex, complex land
mines around this area. But you can mitigate the damage
by not stopping at the boundaries of the code, right.
You have to push into documentation, into education, into into
(33:57):
blog posts, into stack overflow, all these places that that
we kind of see a particular message that's really vital
to get as clocus as close as you can and
push those ideas in. So from kind of the way
the time libraries are carved up to the way that
(34:17):
you've kind of taken an increased leadership role in the language,
I think it's really cool.
Speaker 5 (34:23):
Yeah, I think it helps a lot that we have
great developer experience tools like you know, uh xtoc and
hex stocks. As library maintainers, you try really really hard
to make sure that your documentation.
Speaker 2 (34:35):
Is super clear.
Speaker 5 (34:36):
You try to include as many examples as possible, and
uh it's kind of like a point of pride if
your if your hex stocks page looks you know, super
clean and and you don't have to turn to stack
overflow for questions because you can just look at the
docs and you're you're all your questions are answered right there.
So I definitely feel that that's something that the Electric
community has gotten right, is focusing on tooling so that
(34:58):
people can be self sufficient and teach themselves.
Speaker 8 (35:01):
I agree that a whole having the documentation generator in
with the language makes it so much easier when you're
writing libraries because you're not searching for like how do
I get docs into this, so as a response, you
can pretty much have good documentation all the libraries, which
is really nice. Speaking of kind of other libraries, is
there any other projects that you're contributing to right now?
Speaker 3 (35:20):
Right now, I'm not working as much a OVID source
as I used to before. I would contribute to t
set data, cander that I made, and also elix to itself,
Ecto Phoenix, trying to mostly trying to push some of
these data and time things into it, and in some
cases also some other details. But yeah, I'm still maintaining
(35:44):
t set data and that's kind of the main thing
right now.
Speaker 8 (35:47):
I have to say, I'm very thankful for your work
because I've used it quite a bit. Throughout the years,
every time I've been dealing with day and time, especially
before daytime, and now you've daytime made it into the
Standard library. It was always a bit more difficult before,
but now it's it's just a natural piece of the language.
Speaker 9 (36:04):
It's so simple, So I thank you for that.
Speaker 5 (36:06):
Sure, yeah, I definitely want to echo that. I mean,
looking at X right now, tz data is almost the
twenty almost twenty four million downods of all times. I
think everyone here definitely appreciates the work you put into it,
and plenty of people around the world, So thanks well.
Speaker 1 (36:21):
On that note, I think this is a great time
to transition into picks and what we'll do is we'll
just kind of round robin and if anybody has any recommendation,
suggestions or links that they'd like to share, and now's
the time. I'm going to go first, and I'm going
to pick a blog post from back in May from
Yu Lao on calendar and TIMEX and the Elixir Standard
(36:45):
Library's expansion of dealing with a lot of these date,
day time, time zone capabilities. I thought it was a
really nice introduction to the topic. It was a really
nice kind of call for using these tools and libraries
the right way and at the right time, and definitely
appreciated you putting it out and doing some of this
really really critical education work on top of all of
(37:05):
the open source contributions that you've given us in this area.
So would love for some of our listeners to check
that out. And with that, I will hand over our
picks to Bruce.
Speaker 2 (37:15):
Yeah, I've got a couple.
Speaker 4 (37:17):
Of course, as Garatio as a sponsor, there's always a
Grozio pick, so I'll start there, So the Grazio pick.
I just finished the recording session with Brian Trottwine for
a short video series called Why Things Fail And for
those of you who don't know, and Brian is a
marvelous storyteller and failure expert expert, so he's done talks
(37:42):
on from everything to turnobyl to This particular series is
starting with one called the Boston Molasses Flood and there's
a great book on that called Dark Tide. So subscribe
to a video channel YouTube dot com slash c slash groxio.
The one is every time that I would try to
(38:03):
do some datemath and actually try to sneak it into
our code base, James Gray would find it and he
would respond with always with just a single link. And
this is a famous YouTube video called the Problem with
Time and time Zones with an excellent video video author
(38:25):
called computer File tremendous series. This one has I don't know,
a couple million downloads or something like that, so check
it out.
Speaker 9 (38:33):
Wonderful.
Speaker 1 (38:33):
Thanks Bruce. And how about Eli and.
Speaker 9 (38:35):
He picks for us?
Speaker 3 (38:36):
First of all, where I work at three Real, we
are hiring, so if you're interested in working with the lakser,
let me know. Another pick is this book that I like,
if not for anything else, that mentions having units of
measure when you program things. So it's domin Modeling made
(38:58):
Functional by Scott Collection, and it talks about the main
modeling and uses f sharp as an example. And I
think it's interesting to at least read through and it
can give you an example of how to do that
in functional language. So I think that maps well to Elixir.
(39:21):
And yeah, like I said, the one thing that especially
is relevant also to to this, even though it's a
small detail, is how you it's important to save little
details such as unit of measure like you have instead
of having a monitor rally being an integer of one,
you have the USD or c a d in stuff.
(39:45):
In addition to that it is an important detail then
can mean your data.
Speaker 2 (39:51):
Is useful or useless. And also in general, my blog
is creative deletion a calm. That's it.
Speaker 1 (40:01):
Awesome, Thank you. Yeah, I've been enjoying checking out your
blog lately, so definitely echo that recommendation. Any picks from.
Speaker 9 (40:08):
Unique up, I actually don't have any picks today, fortunately.
Speaker 1 (40:11):
Okay, you'll just owusun for next time, Alex, anything from you.
Speaker 5 (40:16):
Yeah, sure. So I got two Elixir related picks for today.
So the first one is a blog post by I
Guess Dasky on dev dot two. It's called an IoT
Birdhouse with Elixir nerves and Phoenix live components. So I
found out to be a pretty cool article kind of
spanning from you know, the web and hardware and tying
(40:36):
it all together. So I think that was a really cool,
really cool read. My next pick is a blog post
that I wrote my blog, and it's called dynamically Configure
your plugs at runtime, and I outline kind of the
problems I was having with dynamically executing plugs or configuring
them at run time, and I wrote two libraries, one
called Unplugged, which I was surprised to get that hex
(41:00):
package name, and one called replug and uh, you know,
those kind of solve problems that I was having, and
I'm sure that other people have had similar issues. So
I put my learnings up on the blog and hopefully
people find those two as useful.
Speaker 1 (41:13):
I'm definitely gonna check out that last one because yeah,
not a stranger to that problem.
Speaker 9 (41:18):
All right.
Speaker 1 (41:19):
I think that's it for today's episode. Thank you so
much for joining us. Thank you to our guests Lal
and hopefully we'll have a chance to talk with you
again in the future. And the shout out for upcoming
Alixir KOMPF. I think this episode will air before then.
If not, then of course you all are very confused.
But if it does air before, Alexa Kromp, you haven't
gotten your ticket yet, it's all the time, all right.
Speaker 9 (41:39):
Thanks everybody, Thank you, Thanks everyone. Thanks
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.