In Erlang, i can get the Unix Epoc Timestamp by the code below:
{MegaSecs, Secs, MicroSecs} = now().
UnixTime = MegaSecs * 1000000 + Secs.
OR (as suggested by some sites)
calendar:datetime_to_gregorian_seconds(calendar:universal_time())-719528*24*3600.
However that conversion has occured for the result of erlang:now(). What if i have a given date time value in the format: "YYYY-MM-DD HH:MI:SS" e.g. "2012-12-30 15:13:40"
The time being in 24 hour format. This website gives the complete picture of what i need to be able to do in erlang.
How can i interchangeably convert from human readable formats to unix epoch timestamps and vice versa "at will", in my code. Such that if in my programs i store the timestamps as Unix Epochs, at the time of reading them, i can retrieve the human readable format automatically from the unix timestamp value or viceversa.
You can use this lib: https://github.com/selectel/tempo
tempo is a library for parsing and formatting dates in Erlang. It provides a clean and nice interface to libc's strptime and strftime functions, which are unfortunately missing from Erlang's standard library.
As well as tempo there's qdate:
https://github.com/choptastic/qdate
Would be interested to hear comparisons :)
Related
I do appreciate why differences between two LocalDateTime instance are expressed as Periods and not Durations, but I could not find a reason why Period is a class and not a struct.
I am helping to port a codebase that did lots of this:
DateTime t1;
DateTime t2;
TimeSpan diff = t2-t1;
// After port, with a surprising allocation
LocalDateTime t1;
LocalDateTime t2;
Period diff = t2-t1;
It seems like a bit of a perf/GC pitfall, and I'm just curious why Period is a class and not a struct?
The main reason for Period to be a class is that it would be huge - it has 6 long fields and 4 int fields. That would be 64 bytes - an awful lot to pass as a method argument etc. While some other structs in Noda Time are "pretty big" they're not that big.
But it's worth noting that the two pieces of code do radically different things. The Noda Time equivalent of TimeSpan isn't Period; it's Duration, which is a struct. If you don't need a calendrical calculation, you might want to consider converting your two LocalDateTime values to Instant values in UTC (or avoid using LocalDateTime to start with), and then take the difference between those two instants.
Internally, there are non-allocating ways of getting "the number of days" between dates, for example... we could potentially expose something like that publicly, but I think it would be worth doing benchmarking first to prove this is really important. (The GC is pretty good at collecting very-temporary objects. Sure, it's not free - but I think code would have to be doing very little other than this for it to become a major factor.)
I have a given time string 14:00 and want to subtract 5 Minutes.
How can this be done in bash?
Gives me a datetime object: date -d "14:00" +'%H:%M' -> 14:00
I tried subtract: date -d "14:00 - 5min" +'%H:%M'
-> Gives 21:01. But Why?
Desired result if of course: 13:55.
The following works:
$ date -d "14:00 5 minutes ago" +'%H:%M'
13:55
I can't explain why though.
From the info page for gnu date:
Our units of temporal measurement, from seconds on up to months,
are so complicated, asymmetrical and disjunctive so as to make
coherent mental reckoning in time all but impossible. Indeed, had
some tyrannical god contrived to enslave our minds to time, to make
it all but impossible for us to escape subjection to sodden
routines and unpleasant surprises, he could hardly have done better
than handing down our present system. It is like a set of
trapezoidal building blocks, with no vertical or horizontal
surfaces, like a language in which the simplest thought demands
ornate constructions, useless particles and lengthy
circumlocutions. Unlike the more successful patterns of language
and science, which enable us to face experience boldly or at least
level-headedly, our system of temporal calculation silently and
persistently encourages our terror of time.
—Robert Grudin, ‘Time and the Art of Living’.
.
and, more relevantly:
The time may alternatively be followed by a time zone correction,
expressed as ‘SHHMM’, where S is ‘+’ or ‘-’, HH is a number of zone
hours and MM is a number of zone minutes
Your attempt to perform arithmetic is failing, and date is trying to parse the expression "- 5min" as a time zone correction.
I'm trying to retrieve documents newer than some timestamp using the AQL query below. The field date was stored as ISO strings like 2015-01-28T15:39:00.503Z. Is there any other proper data type to store dates in ArangoDB?
for m in messages
filter m.date > "2015-01-28T00:00:00"
return m
EDIT:
According to this thread, ArangoDB does not support any type of dates. They suggest ISO string comparisons as the way to go. Can anyone confirm that?
As far as I know there is only one additional format: the number of milliseconds since a fix point of time (1.1.1970?) see docu, search for "utc". But since this format is not very convient if you want to work with local times, I personally prefer to work with the strings (and typically Skiplists on them).
like the answer of the #agustin-s, Try to set the date in number format milliseconds.
example Aql,
for v in tweet
filter v.timestamp>=(DATE_TIMESTAMP(DATE_NOW()) - (6*10000))
return v._id
I'm writing a program that receives data in the form of GPRMC NMEA sentences and outputs it as specified by GTFS-realtime.
GTFS-realtime wants a "timestamp" value, and describes it as such:
Moment at which the vehicle's position was measured. In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC).
Here's a complete GPRMC sentence, with the relevant fields bolded:
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
The above tells me that the reading was taken at 12:35:19 on 23/03/94.
According to http://www.epochconverter.com/, this date and time is represented as 767104519 in POSIX time.
Using Erlang, what is the best way to go about deriving a POSIX timestamp from a GPRMC NMEA sentence?
How do you convert epoch time (unix timestamp) to standard time in D? Is there a way to customize the format?
You really should separate questions out, not ask two completely different questions at the same time.
How do you convert epoch time (unix timestamp) to standard time in D?
If you need to convert from unix time to SysTime's "std time," then you use unixTimeToStdTime:
assert(unixTimeToStdTime(0) == (Date(1970, 1, 1) - Date.init).total!"hnsecs");
So, if you do SysTime(unixTimeToStdTime(0)), you'll get a SysTime in your local time zone at the point in time when it was midnight, January 1st 1970 in UTC (i.e. the epoch time). Unlike the other SysTime constructors, it does not treat the time it's given as being in the timezone that it's given. Rather, it just sets its stdTime to the given value, and it's timezone to the given value. So, to construct an identical SysTime with the other constructors, you'd do something like
auto epochInLocalTime = SysTime(Date(1970, 1, 1), UTC()).toLocalTime();
If you want to convert in the opposite direction, stdTimeToUnixTime will convert a std time to a unix time. However, SysTime has toUnixTime on it, making it so that you generally don't need stdTimeToUnixTime.
time_t epoch = epochInLocalTime.toUnixTime();
However, one thing to be aware of is the fact that std.datetime truly deals with unix time - time_t is always considered to be in UTC. The reason that this matters is that for some inexplicable reason, Windows applies the local time's DST to time_t so that the UTC offset never changes, which means that it's wrong for a good chunk of the year. It works with all of the Microsoft's functions which use time_t, because they expect that nonsense, but you'll have interoperability problems if you try and use a Windows time_t with another box or with a library like std.datetime which actually uses time_t correctly.
Is there a way to customize the format?
You mean that you're looking for a way to provide a user-defined format for a string representing the time (like C's strftime)? std.datetime doesn't have that yet. The API still needs to be designed for it. Some discussion has taken place, but it hasn't been settled on yet. So, it'll happen eventually, but it could be a while.
In the interim, you have toISOString, toISOExtString, and toSimpleString, which use the ISO format, the ISO extended format, and Boost's simple string format respectively. In general, I'd suggest using toISOExtString, because it's both easily read by humans and standard. It's also generally best to put it in UTC (e.g. sysTime.toUTC()) when communicating with other computers (as opposed to printing it out for humans), because then the time zone is part of it, unlike with LocalTime, which doesn't append the time zone.
If you haven't read this article on std.datetime yet, then I suggest that you do, since it should give you a good overview of the module and how to use it.
I'm not familiar with D, but according to std.datetime, you could use these steps
long unixTimeToStdTime(time_t)
struct SysTime(long stdTime)
SysTime.dayOfGregorianCal()
struct Date(int day)
Date.toISOExtString()