Calling Timex.to_naive_datetime to convert to a naive datetime without the timezone subtracts an hour from the input datetime
I have tried other timezones and ruled out the possibility of daylight saving time conversion.
d = %DateTime{
year: 2000,
month: 2,
day: 29,
zone_abbr: "CET",
hour: 23,
minute: 0,
second: 7,
microsecond: {0, 0},
utc_offset: 3600,
std_offset: 0,
time_zone: "Europe/Warsaw"
}
#=> # DateTime<2000-02-29 23:00:07+01:00 CET Europe/Warsaw>
Timex.to_naive_datetime(d)
#=> ~N[2000-02-29 22:00:07]
d2 = %DateTime{
year: 2019,
month: 3,
day: 2,
zone_abbr: "PST",
hour: 23,
minute: 0,
second: 7,
microsecond: {0, 0},
utc_offset: 3600,
std_offset: 0,
time_zone: "America/Los_Angeles"
}
#=> #DateTime<2019-03-02 23:00:07+01:00 PST America/Los_Angeles>
Timex.to_naive_datetime(d2)
#=> ~N[2019-03-02 22:00:07]
I am expecting the first datetime to be converted to ~N[2000-02-29 23:00:07], but the output is ~N[2000-02-29 22:00:07].
Both of the structs you create contain utc_offset: 3600, which is UTC+1.
#DateTime<2000-02-29 23:00:07+01:00 CET Europe/Warsaw>
#DateTime<2019-03-02 23:00:07+01:00 PST America/Los_Angeles>
How did the +01:00 that get there for America/Los_Angeles? It's not valid for that timezone. If I generate the date using one of the standard functions:
d3 = Timex.to_datetime({{2019,3, 2}, {23, 0, 7}}, "America/Los_Angeles")
#=> #DateTime<2019-03-02 23:00:07-08:00 PST America/Los_Angeles>
Timex.to_naive_datetime(d3)
#=> ~N[2019-03-03 07:00:07]
I get the correct timezone offset. It seems Timex.to_naive_datetime/1 returns the UTC value of the timezone. If you just want to drop the timezone information, you can use DateTime.to_naive/1:
d1
#=> #DateTime<2000-02-29 23:00:07+01:00 CET Europe/Warsaw>
DateTime.to_naive(d1)
#=> ~N[2000-02-29 23:00:07]
Related
I have a datetime string this format
44340.5416666667 but i want to convert this to 5/24/2021 3:00:00 PM - 4:00:00 PM format. How can i parse that with golang? I tried some convert function but it didn't work.
According to https://kb.paessler.com/en/topic/1313-how-do-i-translate-prtg-timestamp-values-format-to-normal-time-format, the timestamp format used by PRTG seems to be defined as the value of days since Dec 30, 1899.
Following the above link, the following Go code should convert the timestamp into a Go Time instance:
prtg := 44340.5416666667
// substract number of days between Dec 30, 1899 and Jan 1, 1970 and convert to millis
millis := int64((prtg - 25569) * 86400 * 1000)
t := time.Unix(0, millis*int64(time.Millisecond))
println(t.Format("1/2/2006 03:04:05 PM"))
According to prtg timestamp mentioned in Gregor Zurowski's comment,
convert your time to nano seconds (minimum unit in time to more accurate) and add unix nano of 1899-12-30 12.00 midnight.
re convert it to time and format it as below
package main
import (
"fmt"
"time"
)
func main() {
startDate := time.Date(1899, 12, 30, 0, 0, 0, 0, time.UTC).UnixNano()
timeVar := 44340.5416666667 //your time variable
duration := startDate + int64(float64(24*60*60) * timeVar * 1e9) //duration since start date in nanoseconds
fmt.Println(time.Unix(0, duration).Format("1/2/2006 03:04:05 PM"))
}
I'm running into an issue when I'm trying to create a histogram of specific createdAt datetimes for orders. The issue is that even after created timezone aware datetimes, the .weekday() shows up as the same day, even though it should be a different time
The code I'm using to test this occurrence is as follows:
import datetime
import pytz
value = {
'createdAt': '2017-04-24T00:48:03+00:00'
}
created_at = datetime.datetime.strptime(value['createdAt'], '%Y-%m-%dT%H:%M:%S+00:00')
timezone = pytz.timezone('America/Los_Angeles')
created_at_naive = created_at
created_at_aware = timezone.localize(created_at_naive)
print(created_at_naive) # 2017-04-24 00:48:03
print(created_at_aware) # 2017-04-24 00:48:03-07:00
print(created_at_naive.weekday()) # 0 (Monday)
print(created_at_aware.weekday()) # 0 (should be Sunday)
The problem is that you need to actually change the datetime to the new timezone:
>>> timezone('UTC').localize(created_at)
datetime.datetime(2017, 4, 24, 0, 48, 3, tzinfo=<UTC>)
>>>timezone('UTC').localize(created_at).astimezone(timezone('America/Los_Angeles'))
datetime.datetime(2017, 4, 23, 17, 48, 3, tzinfo=<DstTzInfo 'America/Los_Angeles' PDT-1 day, 17:00:00 DST>)
I have one date-time in Ecto.DateTime and the 2nd one in DateTime. How can I convert them to each other? Isn't there a easy way without external dependencies? There's nothing in the documentation. One of them has to_erl, another from_unix, but there's no overlap in methods, such as to_unix/from_unix or to_erl/from_erl or something similar.
The equivalent of Ecto.DateTime is NaiveDateTime, since neither of them store a timezone, while DateTime does. Erlang datetimes also do not have a timezone, which is why there's no to_erl and from_erl in DateTime.
You can first convert to NaiveDateTime and then use DateTime.from_naive/2 along with the timezone your datetime is in (Elixir only supports Etc/UTC as of Elixir 1.4):
iex(1)> Ecto.DateTime.utc |> Ecto.DateTime.to_erl |> NaiveDateTime.from_erl! |> DateTime.from_naive!("Etc/UTC")
%DateTime{calendar: Calendar.ISO, day: 8, hour: 4, microsecond: {0, 0},
minute: 49, month: 2, second: 9, std_offset: 0, time_zone: "Etc/UTC",
utc_offset: 0, year: 2017, zone_abbr: "UTC"}
iex(2)> DateTime.utc_now |> DateTime.to_naive |> NaiveDateTime.to_erl |> Ecto.DateTime.from_erl
#Ecto.DateTime<2017-02-08 04:50:23>
If you were using Ecto.DateTime earlier though, you probably want to use NaiveDateTime now.
The month format specifier doesn't seem to work.
from datetime import datetime
endDate = datetime.strptime('10 3 2011', '%j %m %Y')
print endDate
2011-01-10 00:00:00
endDate = datetime.strptime('21 5 1987', '%j %m %Y')
print endDate
1987-01-21 00:00:00
Now, according to the manual the manual:
%m = Month as a decimal number [01,12].
So, what am I missing, other than the hair I've pulled out trying to understand why my django __filter queries return nothing (the dates going in aren't valid!)? I've tried 03 and 05 to no avail.
Versions of things, platform, architecture et al:
$ python --version
Python 2.7
$ python3 --version
Python 3.1.2
$ uname -r
2.6.35.11-83.fc14.x86_64 (that's Linux/Fedora 14/64-bit).
You can't mix the %j with others format code like %m because if you look in the table that you linked %j is the Day of the year as a decimal number [001,366] so 10 correspondent to the 10 day of the year so it's 01 of January ...
So you have just to write :
>>> datetime.strptime('10 2011', '%j %Y')
datetime.datetime(2011, 1, 10, 0, 0)
Else if you you wanted to use 10 as the day of the mount you should do :
>>> datetime.strptime('10 3 2011', '%d %m %Y')
datetime.datetime(2011, 3, 10, 0, 0)
Isn't %j the "day of year" parser, which may be forcing strptime to choose January 21, overriding the %m rule?
%j specifies a day of the year. It's impossible for the 10th day of the year, January 10, to occur in March, so your month specification is being ignored. Garbage In, Garbage Out.
I have a date/time field from a shopping cart API feed, but I don't know what format it is in and I don't have access to the database.
What could [1252457867] be for a date?
These dates are all within the last couple weeks
Any ideas?
Clearly a unix timestamp.
1252457867 = 09 Sep 2009 - 02:57:47
This sounds like seconds since the Unix Epoch (January 1, 1970).
That looks like seconds elapsed since Jan. 1st, 1970 12:00AM.
Use this function to get the date:
var baseDate = new DateTime(1970, 1, 1, 0, 0, 0);
var transactionDate = baseDate.AddSeconds(1252457867);
This will output {9/9/2009 12:57:47 AM} PST
**EDIT: **
If you need UTC:
var utcDate = baseDate.AddSeconds(1252457867).ToUniversalTime();
This outputs {9/9/2009 7:57:47 AM}
--Adam