I am trying to get the local date and converting it to a ‘YYYY-MM’ format, and develop on both a windows and mac system. On the windows machine, the line of code I ended up with was:
and this produced the exact results I needed. However, when I pulled down on the Mac, ran my mix deps.get and ecto migration, trying to create a new date causes an “invalid_date” error, like this:
Can you please share a full example of how you construct the date and try to format it on both machines and what versions of elixir, Erlang and Timex are installed on those machines respectively?
Hey there! Both machines have: Elixir 1.4, Timex 3.0, and Erlang 20.2.
This is how the date is created/formated:
def seed_starting_categories(user) do
Repo.insert(
Ecto.build_assoc(user, :categories, %Category{
id: Ecto.UUID.generate(),
name: "My First Category",
date: Timex.format!(Timex.to_datetime(Timex.local), "{YYYY}-{0M}")
})
)
end
Can you IO.inspect the result of Timex.local in both environments?
Timex.local/0 is documented to maybe return a Timex.AmbiguousDateTime.t() or an :error-tuple, which both are not understood by Timex.to_datetime, which itself will return an :error-tuple then and Timex.format! blows up.
I tried to replicate something of that, on my Windows I can run the Timex.format!(Timex.to_datetime(Timex.local), "{YYYY}-{0M}") snippet, and got 2018-03 as result. Timex.local returned #DateTime<2018-03-08 17:46:57.333000-03:00 -03 America/Sao_Paulo>.
Then I switched to WSL (Ubuntu 16), I ran the same snippets on a clean lock file and got:
There was a bug report in Septembre '17 which was fixed then.
Releases since that fix are 3.1.25, 3.2.0 and 3.2.1.
Also it works for me (created something to test now to confirm or unconfirm the behaviour)… Versions as @joaoevangelista.
Also I’ll throw tzdata 0.5.16 into the mix (according to mix.lock). My system is an arch linux with 4.15.5 Kernel and tzdata 2018c timezone database. My local timezome is Europe/Berlin.
@wakka_wakka please try to update Elixir and Timex first. If the problem persists with current versions, please join the ticket created by @joaoevangelistaor create your own if he hasn’t created one until then.
I searched about timezone issues in other softwares and seems you can rely on environment variables, my Windows’ Powershell gets the correct one, on WSL it didn’t find the variable that threads mentioned, I’ll try to set it up and run again the snippet
Set TZ environment variable to the name of default timezone for example mine would be: export TZ='America/Sao_Paulo'
Is this a bug on Timex? I don’t think so
Maybe include some notes on it? Definitively.
After seeing the comment about the OSX that works, and having my Windows working too, I thought on look about where does a system stores its timezone, because when we set up Ubuntu, for example, it asks us where are we to set the time and formats.
I searched for issues regarding timezones on Unix and stubbed upon some posts and this R one where I saw the usage of the TZ env var. I went to Powershell and used the command to fetch the information, aka: [System.TimezoneInfo]::Local and returned the correct one, then I went to WSL and searched for TZ and there was nothing, I tried to set it to /usr/share/zoneinfo/Brazil/East and returned the error {:error, {:unknown_timezone, "/usr/share/zoneinfo/Brazil/East"}}.
So it tried using the ‘America/Sao_Paulo’ string on the TZ env var and worked as it does on Windows, returning #DateTime<2018-03-08 18:58:46.054746-03:00 -03 America/Sao_Paulo>