presto> select date '0001-01-01';
Expected result: '0001-01-01'
Actual result: '0001-01-02'
Day is increasing by one not sure why.
Can anyone help me on this that how can i resolve this?
If i run the above query on presto-cli then result comes as '0001-01-01' which is expected but when i run same query via SQL workbench then result comes as '0001-01-02' which is actual result.
This is because Presto uses internally Joda Time and Java Time for server APIs and JDBC uses (per JDBC standard) java.sql.Date and related classes.
Both Joda Time and Java Time use proleptic Gregorian calendar. This means they count days as if Gregorian calendar existed since ever.
java.sql.Date (and java.util.Calendar for that matter) uses Julian-Gregorian calendar, which may seem to be more accurate. It accounts for the fact that Julian calendar was used until some day and then Gregorian calendar was and still is used. (Of course, it's not and cannot be accurate, because the cut over date varies from country to country and spans several centuries).
My recommendation is: use varchar for representing historical dates and date times.
Related
I want to be able to convert the current UTC time to a user's timezone, and get the value as a timestamp. Simple.
I seem to be having some difficulty though... this is what I've tried:
Carbon::now()->setTimezone('America/Los_Angeles'); // this works, but returns the time in the format "Y-m-d H:i:s"
So then I tried this:
Carbon::now()->setTimezone('America/Los_Angeles')->timestamp; // for some reason doing this seems to revert the timezone conversion and instead returns the timestamp for the current UTC time? :/
So, I'm using this workaround:
$converted_time = Carbon::now()->setTimezone('America/Los_Angeles');
return Carbon::createFromFormat('Y-m-d H:i:s', $converted_time)->timestamp;
...which gives me what I need, but seems unnecessary. Is there a better way to do this (in one line)?
Thanks.
The Unix Timestamp is per definition the number of second since 1st January 1970 UTC.
If you're trying to calculate the number of second since an other date (like 1st January in Los Angeles), you're calculating something else that is not Unix Timestamp.
To make sense, it's very important that the timestamp as a number would be a non-ambigus representation of a single second that can be used safely worldwide and still represent the same moment. If you have a number that can be different moment regarding from which timezone you're looking at it, you're likely not using the right tool, and would get more safety to store date-time + timezone.
So the very first question, is why would you need to get the number of second since 1st January in Los Angeles?
You can read more here about how to properly work with UTC and why to avoid having a strong dependence in your back-end with calculations in other timezones:
https://kylekatarnls.medium.com/always-use-utc-dates-and-times-8a8200ca3164
I have some SQLite database in which one of the columns has data type as realdate and the column has value as 2453137.5
can anyone please comment on this?
any help is appreciated :)
From SQLlite Docs
SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:
TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.
In your example you are using REAL datatype to store Dates. It will give the output which is not human readable.
For eg., If i'm storing current date and time
CREATE TABLE
IF NOT EXISTS DATEREAL (d1 real);
INSERT INTO DATEREAL (d1)
VALUES(julianday('now'));
SELECT * from DATEREAL;
Output : 2458792.7882345
You can read this using built-in date() and time() as shown below
SELECT
date(d1),
time(d1)
FROM
datereal;
Output :
date(d1) time(d1)
2019-11-05 06:55:03
Check demo here
One of the powerful features of SQLite is allowing you to choose the storage type.
Real number has 2 advantages:
High precision regarding fraction seconds
Longest time range
I got this answer from a user named Zso.
Here's the link to the original post How do DATETIME values work in SQLite?.
Hope this might help you to understand better.
I think there is a bug when querying a release's ReleaseDate field. Let's say I have a release with a ReleaseDate of 04/24/2017 EDT, when I get the response from the API request, and take a peek at the ReleaseDate field for that release, it comes off as 04/25/2017 (in date time format obviously), one day ahead of the actual date. I am building a calendar app for inside use using full calendar, and this bug is really annoying. Am I correct to say that this is a bug? Are there any workarounds that do not involve writing code to fix the date after querying it? thanks.
Pretty sure this is timezone related. Dates in WSAPI are always UTC. Assuming your workspace is configured for Eastern the dates returned probably are the next day:
A release with an end date of 04/24/2017 is probably being returned from WSAPI with a date like 2017-04-25T03:59:59.000Z, which when converted to EDT would be the end of the day on the 24th.
You'll also want to be specific when setting dates since the backend will again try to coerce the date into UTC if there is no time specified. The current behavior or the detail pages is to set it to noon on that day for that timezone. So something like this: 2017-04-24T12:00:00-05:00
Hope that helps. We did a bunch of work across the product and the api's last year to try to provide a more consistent experience working with timezones. It still can be confusing, but a good rule of thumb is to always be specific and include a time and timezone offset when working with dates using the api.
If you're using App SDK, the moment.js library is already included and is super handy for working with dates:
https://help.rallydev.com/apps/2.1/doc/#!/guide/third_party_libs-section-moment.js-2.10.3
My table has a category 'timestamp' where the timestamps are formatted 2015-06-22 18:59:59
However, using DBVisualizer Free 9.2.8 and Vertica, when I try to pull up rows by timestamp with a
SELECT * FROM table WHERE timestamp = '2015-06-22 18:59:59';
(directly copy-pasting the stamp), nothing comes up. Why is this happening and is there a way around it?
FYI, saying "the timestamps are formatted 2015-06-22 18:59:59" is incorrect if you are indeed using a TIMESTAMP type. Such types have their own internal representation of a date-time value, almost always a count since epoch. In your case with Vertica, 8 bytes are used for such storage. The formatting of the date-time value happens when a string representation is generated. Never confuse the string representation with the date-time value. Conflating the two may well be related to your problem/confusion.
A few different thoughts about possible problems…
String Literals
Are you sure Vertica takes strings as timestamp literals? That format you used is common SQL format. But given that Vertica seems to be a specialized database, I would double-check that.
If strings are not allowed, you may need to call some kind of function to transform the string into a date-time values.
Fractional Second
As the comment by Martin Smith points out, the doc for Timestamp-related data types in Vertica 7.1 says those types can have a fractional second to resolution of microseconds. That means up to 6 decimal places of a fraction.
So if you are searching for "2015-06-22 18:59:59" but the stored value is "2015-06-22 18:59:59.012345", no match on the query.
Half-Open
The fractional seconds issue described above is often the cause of problems people have when handling a span of time. If you naïvely try to pinpoint the ending time, you are likely to have problems. Seeing the "59:59" in your example string makes me think this applies to you.
The better approach to spans of time is "Half-Open" (or Half-Closed, whatever) where the beginning is inclusive while the ending is exclusive. Common notation for this is [). In comparison logic this means: value >= start AND value < stop. Notice the lack of EQUALS SIGN in the stop comparison. In English we would say "look for an hour's worth of invoices starting at 2:00 PM and going up to, but not including, 3:00 PM".
Half-Open for a week means Monday-Monday, for a month the first of one month to the first of the next month, and for a year the January 1 of one year to January 1 of the following year.
Half-Open means not using BETWEEN in SQL. SQL's BETWEEN has often be criticized. Instead do something like the following to look for an hour's worth of invoices. Notice the Z on the end of string literal which means "UTC time zone" ("Z" for "Zulu"). (But verify, as my SQL syntax may need fixing.)
SELECT *
FROM some_table_
WHERE invoice_received_ >= '2015-06-22 18:00:00Z'
AND invoice_received_ < '2015-06-22 19:00:00Z'
;
This query will catch any values such as '2015-06-22 18:59:59.654321" which seems to be eluding you.
Reserved Word
I hope you have not really named your table 'table' and your column 'timestamp'. Such use of keywords and reserved words can cause explicit errors or more subtle weird problems.
Tip: The easy way to avoid any of the over a thousand reserved words in various databases is to append a trailing underscore. The SQL standard explicitly promises to never using a trailing underscore in its reserved words. So use "timestamp_" rather than "timestamp". Another example: "invoice_" table and "received_" column. I recommend doing that as a habit on everything your name in SQL: columns, tables, constraints, indexes, and so on.
Time Zone
You are using the TIMESTAMP which is short for TIMESTAMP WITHOUT TIME ZONE. Or so I presume; the Vertica doc is vague but that is the common usage as seen in the Postgres doc, and may even be standard SQL.
Anyways, TIMESTAMP WITHOUT TIME ZONE is usually the wrong type for most business purposes. The WITH time zone is misnamed and often misunderstood as a consequence: It means "with respect for time zone" where data inputs that include an offset or other time zone information from UTC are adjusted to UTC during the INSERT/UPDATE operations. The WITHOUT type simply ignores any such offset or time zone information.
The WITHOUT type should only be used for the concept of a date-time generally without being tied to any one locality. For example, saying "Christmas this year starts at beginning of December 25, 2015". That means in any time zone rather than a specific time zone. Obviously Christmas starts earlier in Paris, for example, than in Montréal.
If you are timestamping legal documents such as invoices, or booking appointments with people across time zones, or scheduling shipments in various localities, you should be using WITH time zone type.
So back to your possible problem: Test how Vertica or your client app or your database driver is handling your input string. It may be adjusting time zones as part of the parsing of the string using your client machine’s current default time zone. When sent to the database, that value will not match the stored value if during storage no adjustment to UTC was made.
Tip: Generally best practice is to do all your storage and business logic in UTC, adjusting to local time zones only where expected by user.
We are using a Vertica database with table columns of type timestamptz, all data is inserted according to the UTC timezone.
We are using spring-jdbc's NamedParameterJdbcTemplate
All queries are based on full calendar days, e.g. start date 2013/08/01 and end date 2013/08/31, which brings everything between '2013/08/01 00:00:00.0000' and '2013/08/31 23:59:59.9999'
We are trying to modify our queries to consider timezones, i.e. I can for my local timezone I can ask for '2013/08/01 00:00:00.0000 Asia/Jerusalem' till '2013/08/31 23:59:59.9999 Asia/Jerusalem', which is obviously different then '2013/08/01 00:00:00.0000 UTC' till '2013/08/31 23:59:59.9999 UTC'.
So far, I cannot find a way to do so, I tried setting the timezone in the session:
set timezone to 'Asia/Jerusalem';
This doesn't even work in my database client.
Calculating the difference in our Java code will not work for us as we also have queries returning date groupings (this will get completely messed up).
Any ideas or recommendations?
I am not familiar with Veritca, but some general advice:
It is usually best to use half-open intervals for date range queries. The start date should be inclusive, while the end date should be exclusive. In other words:
start <= date < end
or
start <= date && end > date
Your end date wouldn't be '2013/08/31 23:59:59.9999', it would instead be the start of the next day, or '2013/09/01 00:00:00.0000'. This avoids problems relating to precision of decimals.
That example is for finding a single date. Since you are querying a range of dates, then you have two inputs. So it would be:
startFieldInDatabase >= yourStartParameter
AND
endFieldInDatabase < yourEndParameter
Again, you would first increment the end parameter value to the start of the next day.
It sounds like perhaps Vertica is TZ aware, given that you talked about timestamptz types in your answer. Assuming they are similar to Oracle's TIMESTAMPTZ type, then it sounds like your solution will work just fine.
But usually, if you are storing times in UTC in your database, then you would simply convert the query input time(s) in advance. So rather than querying between '2013/08/01 00:00:00.0000' and '2013/09/01 00:00:00.0000', you would convert that ahead of time and query between '2013/07/31 21:00:00.0000' and '2013/08/31 21:00:00.0000'. There are numerous posts already on how to do that conversion in Java either natively or with Joda Time, so I won't repeat that here.
As a side note, you should make sure that whatever TZDB implementation you are using (Vertica's, Java's, or JodaTime's) has the latest 2013d update, since that includes the change for Israel's daylight saving time rule that goes into effect this year.
Okay, so apparently:
set time zone to 'Asia/Jerusalem';
worked and I just didn't realize it, but for the sake of helping others I'm going to add something else that works:
select fiels at time zone 'Asia/Jerusalem' from my_table;
will work for timestamptz fields