I'm going through this list of dates and times and I've been googling for a few days now and haven't figured out this time format:
201612102200038814 -> 10.12.2016 19:01
201611182200029224 -> 18.11.2016 11:55
201611162200028449 -> 16.11.2016 19:06
2016080521998919 -> 5.8.2016 19:47
2016091522320593 -> 15.9.2016 18:53
It's obvious that the first 8 digits (20161210) are YYYYMMDD, but latter part doesn't make any sense to me....
Do you have any ideas? Is it even a valid time format?
It seems to be some kind of timestamp, since 2,200,029,224 is very close to 2,200,028,449, and the dates of each are only 2 days apart. So the difference is 775, and the date difference is roughly 1.75 days.
The difference between the first two is 9590, which is larger, which makes sense since the difference between those dates is almost a month.
The oldest date you have in the list also has the smallest timestamp, which is consistent with this theory.
The ratios also match up. 775 / 1.75 days = 442. 9590 / 22 days = 435. If I calculated exact seconds differences I bet these ratios would match up nearly perfectly. So then each hour the timestamp goes up by 18 (roughly), or 3 every 10 minutes. This is a pretty bizarre timestamp, but it does fit, and can be used to calculate dates from the given timestamp.
Related
I'm creating a customized function that does some calculations for a given time.
When a time is entered in a cell, for example 4:00 PM, this is automatically converted into a date, in this case 12/30/1899 16:00:00 and when the function getTheMinutes() is called, it returns 2 instead of 0.
function getTheMinutes(dateTime){
return dateTime.getMinutes();
}
The behavior of the function is different if it's used for a most recent date like 5/1/2019 16:00:00.
I want the user to be able to just write a time in a cell then use the customized function in another cell. Please let me know your thoughts.
Now that you have indicated the time zone for your spreadsheet I can confirm what #RobG deduced almost a day ago, which is that Guatemala adjusted its difference relative to UTC. Something you have confirmed is treated as by two minutes with effect from October 5, 1918.
More specifically, the adjustment was of 2 minutes and 4 seconds and effective from 03:00 that day:
(Source IANA Version 2019b file northamerica.)
There have been very many such minor adjustments around the world over the years (even between towns in the same country) and adjustments continue, though usually of a whole hour – between 'standard' and Summer time. Sheets has very properly recognised that "normal arithmetic" 'does not work' across such a transition and while noon yesterday to noon today for example is normally, for any one specific location, a difference of 24 hours it is often 23 hours or 25 hours on the day that clocks go forward/back.
And the moral of the story is to beware of obliging Sheets to assume, for want of a specific date, that is has the index number 0 - i.e. is December 30, 1899.
I made some testing, and I found out that the formula is giving a wrong result any minute before 10/5/1918 0:03:00, from that DateTime on, the formula is working as expected.
Here is my sheet https://docs.google.com/spreadsheets/d/1psm8_GJYRczO53TILJCOzo0p4GpnS-ooiGWqOJrC8ZU/edit?usp=sharing
I would need to do a date validation in my customized formula to make it useful. I don't know why google sheets is choosing that date as default when just a time is typed in a cell, I think it should be improved.
I want an easy way to have a sum of yesterday, the day before and the day before that total 7 columns (past 7 days)
Then i would like average for L7D, Average LM.
I have made a column in my date that indicate what "today" is and then my idea was to have it sum if today, sum if today-1, sum if today-2 but this does not seem to work
)
Yesterday= CALCULATE(SUM('DanvægtLines'[NAV_Qty]);FILTER('DanvægtLines';'DanvægtLines'[Dato_Anden]>=TODAY()-1)
(It take the sum of quanto, then filters if the 2.date on the order is today)
It is only working with ">=" not if i only use "=" ... witch is ok for yesterday, but the if i want to have only 4 days ago i have to filter yesterday, the day before, and 3 days ago... witch make a very very long code line i dont get why
=(today()-4 wont work)
Ok so after about 15 hours of hair pulling it dawned on me that the table I was referring to was in the date+time format, so fixing that I could use =today()-1
I understand why postgresql uses month,day and second fields to representate the sql interval datatype. A month is not always the same length and a day can have 23, 24 or 25 hours if a daylight savings time adjustment is involved. this is from postgresql documentation.
But I then do not understand why this is not consequently handled both for months and days. see the following query which calculates an exact interval where the number of seconds between two points in time is exactly calculatable:
select ('2017-01-01'::timestamp-'2016-01-01'::timestamp); -->366 days.
postgresql chooses to give a result in days. not in months and not in seconds.
But why is the result days and not seconds? it is NOT defined how long days are (they can be 23,24 or 25 hours long). so why does he not give output in seconds?
Then since the length of months is also not defined, why doesn't postgresql give an output of 12 month instead of 366 days?
He does not care that the length of days is not defined, but obviously he cares that the length of month is not defined.
Why this asymmetrie?
For further explanation, see this query:
select ('10 days'::interval-'24 hours'::interval); --> 10 days -24:00:00
you see that postgresql correctly refuses to answer with 9 days. He is pretty aware of the problem that days and hours cannot be interchanged. But then again why does the first query return days?
I can't answer your question, but I think I can point you in the right direction. I think the book SQL-99 Complete, Really is the most accessible source for understanding SQL intervals. It's available online: https://mariadb.com/kb/en/sql-99/08-temporal-values/.
SQL standards describe two kinds of intervals: year-month intervals and day-time intervals. It does this to prevent month parts and day parts from appearing in the same interval, because, as you already know, the number of days in a month is ambiguous. The number of days in the interval '3' month depends on which three months you're talking about.
I think this is the verbose, standard SQL way to write your first query.
select cast(timestamp '2017-01-01' - timestamp '2016-01-01' as interval day to hour) as new_column;
new_column
interval day to hour
--
366 days
I suspect that you'll find that SQL standards have rules for what a SQL dbms is supposed to do when things like interval day to hour are omitted. PostgreSQL might or might not follow those rules.
postgresql chooses to give a result in days. not in months and not in seconds.
Standard SQL prevents month parts and day parts from appearing in the same interval. Also, the range of valid seconds is from 0 to 59.
select interval '59' second;
interval
interval second
--
00:00:59
select interval '60' second;
interval
interval second
--
00:01:00
I have read in this online PostgreSQL documentation... http://www.postgresql.org/docs/9.4/static/datatype-datetime.html#INTERVAL-STYLE-OUTPUT-TABLE
in the point 8.5.5 something about how to tweak the default Interval Output. . I mean the default interval is shown like this...
00:00:00.000 (if the timedifference is lower than a day or month or year)
1 day 00:00:00.000 (if the timedifference reaches days, but is lower than a month or a year)
1 month 1 day 00:00:00.000 (if the timediffence reaches months, but is lower than a year)
1 year 1 month 1 day 00:00:00.000 (if it reaches years, months, days)
it evens uses plurarl cases (years, mons, days) when their values are greater than one.
All these variations make difficult to any other app when SELECTing (query) this interval values (as text) to convert it to a proper time. So I would like postgresql to always show year, month n days, even if their value are 0 (it could be even better if it could show the date part of the interval like this... 01-11-30, adding zeros to the left side when values are less than ten)
I know I can change the interval to text, using to_char() but I really would like to avoid that, I would like some good fellow postgresql programmer to tell me if it is true that there is a way to tweak the Interval Output as is said in the postgresql documentation.
Thanks Advanced.
PD: two more links about the subject
https://my.vertica.com/docs/7.1.x/HTML/Content/Authoring/SQLReferenceManual/Statements/SET/SETDATESTYLE.htm
http://my.vertica.com/docs/6.1.x/HTML/index.htm#13874.htm
You can set the interval output style, but only to one of a few pre-defined formats that are unambigious on input, and that PostgreSQL knows how to parse back into intervals. Per the documentation these are the SQL standard interval format, two variants of PostgreSQL specific syntax, and iso_8601 intervals.
If you want something familiar and easy to parse, consider using:
SET intervalstyle = 'iso_8601'
and using an off-the-shelf parser for ISO1601 intervals.
Essentially I may have any date and I want to get the proper quarter-end date for the previous quarter.
Three examples:
19/07/2013 -> 30/06/2013
30/06/2013 -> 31/03/2013
28/02/2013 -> 31/12/2012
In Excel VBA it seems using DateAdd to subtract a quarter just subtracts three months from the date, e.g. 19/07/2013 -> 19/04/2013. This is no good for me.
What do you think would be the best way of doing this?
Perhaps extracting the month part and then comparing it to a list of the
possible quarters?
Or maybe having some sort of null date
01/01/2000 and then adding the number of quarters the given date
shows as to this null date and then subtracting a day to get a
previous quarter-end position (although this might cause problems
when the date flips under a year to December 31)?
Please consider:
=IF(MOD(MONTH(A1),3)=0,EOMONTH(A1,-3),
IF(MOD(MONTH(A1),3)=1,EOMONTH(A1,-1),
EOMONTH(A1,-2)))
Edit: There is a better answer in the comments.