Hi.
I didnt copy old known-working code, i did something else.
here is how to get the correct value, provided by an answer below.
datetime_utc_from_posix = unix2datetime(posix_int)
[ below is NOT how to get the correct value]
posix_int = 1710526818
utc_datetime = DateTime(posix_int)
println("utc_datetime = ", utc_datetime)
→ utc_datetime = -43135330-03-29T04:42:25.152
kodintent.
What value do you get if you use:
unix2datetime(mtime_int)
No, not for utc_datetime = DateTime(mtime_int) because is expects a year.
That’s very strange, because I get the same you do, unless I use unix2datetime(mtime_int) which is for that.
Note:
julia> typemax(DateTime)
146138512-12-31T23:59:59
despite that you can go higher, e.g. but a bit higher than this you overflow:
julia> utc_datetime = DateTime(291999699)
291999699-01-01T00:00:00
julia> dump(ans)
DateTime
instant: Dates.UTInstant{Millisecond}
periods: Millisecond
value: Int64 9214620453907200000
julia> bitstring(9214620453907200000)
"0111111111100000111010000111101101001111001011111111100000000000"
we don’t actually need all those years… and we actually probably shouldn’t allow over typemax, so plausibly we could do unix2datetime for you implicitly if the “year” is over some value, e.g. 146138512 which corresponds to:
julia> unix2datetime(146138513)
1974-08-19T10:01:53
I’m not sure what other languages do, but it seems plausible, I doubt constructors are very speed-critical, but this wouldn’t be as general, not work for old timestamps (who cares?, those would use the alternative). This might be thought of as too magical.
For such high numbers I think we can, and should just ignore the optional m[onth] etc:
function DateTime(y::Int64, m::Int64=1, d::Int64=1,
h::Int64=0, mi::Int64=0, s::Int64=0, ms::Int64=0, ampm::AMPM=TWENTYFOURHOUR)
..
i get the correct value. now i realize i have not actually copied code from an old script but done something else.
my bad. i had in mind that i copied some old code but actually i had done something else.
question is from my error in sourcing code. there is no reason for this post to exist as the issue does not exist.
Now that you know, you can use the official solution, but what’s you’re opinion about making it just work (for you and) others? It would then be in 1.11 at beast, and probably not backported to 1.10 (that likely becomes LTS…). It’s a relatively simple change, let’s keep the thread here since I changed the title, clarifying not a bug…
Hi.
(edit: it makes sense that all datetime objects can be made with DateTime(), from any time source. But there is the issue of UTC vs Local. if some cases return UTC and some return local, thats not good. Perhaps DateTimeUtc() and DateTimeLocal() would fix everything.)
… As long as its in the docs and people dont have to work out for themselves if it returns utc or local, and what type/format the input should be, no problem.
My experience using Dates has been quite unpleasant.
I find the names of methods dont inform me about what i will get, and i have spent time throwing things to see what sticks, when i couldnt find what i wanted in the docs, which I found insufficient and ambiguous. i had to work out a lot of things myself and that took way too much time.
In my edit i added “datetime_utc_from_posix = unix2datetime(posix_int)” which tells me exactly what is going on. if the docs had this little bit of extra info, that would make it so easy for me to find what i need.
You can do:
DateTime(Year(2020)) # here with a Year type:
2020-01-01T00:00:00
The problem with any “time source” is that a POSIX timestamp is just an integer (now 64-bit), so by definition not its own source datatype, and its unclear it would help you it it were, then you would only have a trivial wrapper type that you would still have to loo up.
Yes, this is redundant, but it IS documented to do the same as above (also doesn’t seem too bad, though maybe regrettable, how often do you need this, maybe at least the moth should have been non-optional):
julia> DateTime(2020)
2020-01-01T00:00:00
We can’t change that, so it’s a bit of a trap, if you think that integer is a UNIX/POSIX timestamp (an implicit assumption, maybe from other languages?). As I explained we could allow it too, you could do a trivial PR for it, or at least a doc PR. Or at least document more explicitly, that’s not what you get and how to do that…
I don’t believe Julia has anything timezone related, since it doesn’t need it for itself, and I believe it’s available in some package. One policy, or restrictive definition of, for the standard library, is to only add the minimum, actually what Julia needs for itself. It doesn’t preclude documenting something like DateTimeUTC and in what package to find it.
Hi.
now im not sure what you meant earlier by “what’s you’re opinion about making it just work (for you and) others?”
Do you mean to add Posix/Unix(int) like there is already Year(int)?
I dont know how many julia users need to work with dates and time, and how important it is to most users.
I think that datetime objects that have no timezone context are not really datetime objects. As soon as they lose their tz context, they are day-wide time ranges. Not a real DTO.
i think that all languages need DTO with mandatory TZ included.