Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I am trying to run a query but in a part of code that calculate the diference between two timestamps the error below is showed.
00000 - "specified field not found in datetime or interval"
*Cause: The specified field was not found in the datetime or interval.
*Action: Make sure that the specified field is in the datetime or interval
Part of code:
SYSTIMESTAMP - DT_PROP
The type of DT_PROP is TIMESTAMP(6).
I will be thankfull if someone can send me a suggestion to solve this.
Here is what's happening.
SYSTIMESTAMP is a timestamp WITH TIME ZONE. DT_PROP is a timestamp (without time zone). You are taking the difference between two values of different data types.
Oracle will not throw an error; it will make an implicit conversion. Converting from timestamp with time zone to a simple timestamp will lose information; so, Oracle won't do that. Instead, Oracle does the opposite: it up-casts the timestamp (DT_PROP) to a timestamp with time zone. For this, it must make an assumption: it assumes the time zone is the same as your system time zone.
And then it runs into trouble, if your system time zone is DST-aware (daylight saving time) and if the pure timestamp (without time zone) is invalid in that DST-aware time zone.
For example, in Los Angeles (U.S.A), daylight saving time in 2020 began on March 8 - the clock was moved forward one hour at 2 A.M. - meaning that, in one-second intervals, the time right after 01:59:59 was 03:00:00. A time-of-day of 02:30:00, for example, on the date 2020-03-08, simply did not exist.
This is one of the cases when Oracle will throw the exact error you reported. And it is entirely possible that it's the reason it threw it from your code.
Solutions? There are some; but you have a DATA PROBLEM. If the timestamps stored in DT_PROP are supposed to represent times in your DST-aware time zone, and you have an invalid value stored in the column, what's up with that? It's easy to write code around it, but shouldn't your business user be alerted to this first? I believe they should. Then see what they tell you - HOW they want this to be handled; otherwise you would be making a business decision for them, not just a "programming" decision.
Related
A lot of questions have been asked about this subject. The best answer that I found is this one: How to set local timezone in laravel
So the main rule is to keep all database entries in the same timezone.
But I have a specific case where this answer does not work for me. For some models, I have only a date (no datestamp). Example: suppose that I only store the date of when this question was asked (= 2018-01-25). However in Europe it is already 2018-01-26. Someone has a solution for this?
Changing my date field to a datestamp? What with existing dates?
You can use this library jamesmills/laravel-timezone
OR
If you need custom configuration:
Configure your app timezone to UTC.
'timezone' => 'UTC',
You can store different timezones in database column.
When outputting/displaying dates, just format it to use that timezone.
$timezone = 'America/Vancouver';
$model->created_at->setTimezone($timezone);
created_at and updated_at are automatically converted to carbon instances, which makes this easier. If you have other dates that you're using, add them to the protected $dates array on the model and laravel will convert them to carbon instance too. Then you can use carbons setTimezone() to change the date/time to the timezone.
If you're only talking about a date, then there is no time component and thus time zones are irrelevant. For this reason, most platforms do not have a separate date-with-zone type.
You're correct that not every time zone experiences the same date at all times, and that the start of a date and the end of the date occur at different times in different time zones. However, did you notice that in the prior sentence that I had to use the word "time" to rationalize about these points? :-)
Because date and time zone don't come together without time, there's no purpose in keeping them in the same field. Instead, keep two fields in your model - one for the date, and one for the time zone. In many cases, you may even find they belong in two different models.
As a use case example, consider birthdays. Mine is 1976-08-27. That's all it is - just a date. The time zone of my birth is irrelevant, and so is the time zone I'm located in - until I want to evaluate whether it's currently my birthday (or how long until my birthday, etc.) For those operations, my current time zone is important, and so is the start time-of-day and end time-of-day of that time zone. Thus - two different fields.
I am working on my first application for mac which uses Core Data. Since I don't have much software development experience I would like to ask the more experienced developers the following question:
When entering data in some of the forms, user will have to enter a date in couple of the forms. Since app will be on app store and people from different continents will download it (I hope so) I am thinking of allowing the user to select his preferred date format from the preferences panel that I have in my app.
But I am wondering what will happen if after entering 500 or more records, he decide to change the date format again? Will that cause a mess in core data eventually?
Is this good idea or I should keep things simple and just get the system date (user computer date format) and use that date format? What would you do? Any advice will be deeply appreciated.
My advice is to keep date as timeinterval. You can see such method for NSDate.
The interval between the date object and 00:00:00 UTC on 1 January 1970.
So if you get NSDate object from NSDatFormatter object you will be able to obtain time in seconds since 1970. You could store this value in Core Data and use it later for creating NSDate objects. You will be able to use it for different locales and time zones as well as use the correct format.
'Dates' is complex topic and I suggest you to read guides about dates and date formatters.
First is to decide how you should store the date. The answer here is as an NSDate. The NSDate is a single unique precise point in time, thus it in a sense stores both date and time.
This means that for example 1 PM in Berlin and 8 pm in Kuala Lumpur will be the exact same NSDate value (during winter months) but 2 pm in London and 2 pm in Paris the same calendar date will not be the same NSDate value. This is a quite complex topic, read the date and time programming topics documentation from Apple.
Then as you say you need to allow you user to input the date. The way to do that is to use a NSDateFormatter tied to your input control. The formatter can be defined to be as per system settings, which means you will get the localisation you are seeking for free, so that is in fact easy.
The tricky thing you are really facing is to determine what you are really looking to store if it is only the calendar date without an associated time you want to store. For example you decide store the date combined with 12.00 noon in the local timezone. Then if the user shifts to another timezone more than 12 hours away the date may be displayed as the previous date or the next. The safest bet is to store the date combined with 12:00 noon GMT as this is in the middle of the time zone range. There are a few locations 13 and 14 hours off that could exhibit the mentioned problem anyway, but these are small atolls in the pacific and could possibly be safely ignored.
However the the best thing is if you can in fact determine that what you are looking to store is really a precise point in time rather than a date (which is a 24 hour fuzzy definition). For example in a calendar app an event usually takes place at a specific time on a specific date, then store that time and date.
I assume that application code should store time in database always as UTC ( punch me if I am wrong)
Now lets say I want to query everything between 23-mar-2013 to 24-mar-2013 . Should I create a time object and then query something like "23-mar-2013:00:00:00UTC" to "24-mar-2013:24:00:00UTC" or querying just by date is right "23-mar-2013" to "24-mar-2013".
Now the problem comes when I am not in UTC and in a time zone like -7:30 .
Now date queries would go wrong..
So does that mean I should query always with time ?
I am talking in concern to ElasticSearch, Tire, Ruby ( But I think that shouldn't matter)
The implementation absolutely does matter. Querying against one database or another is very different depending on how that database stores date / time values. I suggest you edit your question and make it specific for the technologies that you are using. Show some code if you can.
In general though, you are mixing two concepts and you should probably try to separate them mentally.
The moment something happened, an event time, can be measured by a DateTime combined value - represented as either UTC, or as a value that is offset from UTC where the offset is known. This is often referred to as "Instantaneous Time", "Universal Time", or "Physical Time".
The values that we give to dates and times when talking about them locally, such as "Today", "Yesterday", or "March 29, 2013". Even when we have a time, we are talking about a fraction of a day on a calendar. This is often referred to as "Calendar Time", "Local Time" or "Civil Time".
You can always query and do math with Instantaneous Time. It's unambiguous. However, the concept of "Today" is meaningless. There is no observer to mark the end of one day and the start of the next. (One could argue that the observer is in London, but that's not true during BST.)
Calendar Time is only suitable for querying or math when you have day-level precision and only one observer. So it usually makes a poor representation of something meant to be universal, like an event.
Let's go back to your original question. You said:
I want to query everything between 23-mar-2013 to 24-mar-2013
Right there - you have a problem. What is the context? Who's calendar dates are you talking about? Even though you said March 23, you probably don't mean March 23rd at midnight UTC to March 24th at midnight UTC. You probably mean some other calendar's midnights.
Keep in mind that not every day is 24 hours in length. When time zones switch on and off of daylight savings time (or summer time), the days could be 23 hours or 25 hours in length.
So what to do? First, you need a Time Zone database (like the IANA/Olson/TZ/TZDB/ZoneInfo database for example) Here is one implemented in Ruby.
Now, you need to to know the local time zone of the user. That is - the person that is asking the question that you are showing the query results to. That will involve your own application logic, maybe a selector or picker. If this is a web app, you might want to look at this map-based timezone picker, or at jsTimeZoneDetect.
You should always store events with instantaneous time. Let's just say you store events as UTC (although you might use an offset, we'll ignore that for now).
So you need to know for the date range that the user wants, what UTC times do the start and end dates of your query map to? For example, say we are in India using the Asia/Calcutta time zone. We would convert 23-mar-2013 00:00 - 24-mar-2013 00:00, to the UTC equivalent 22-mar-2013 18:30 - 23-mar-2013 18:30.
Then you can use those UTC DateTime values to query the database.
When you return the results to your user, you will probably want to convert UTC back to local time so they understand the results they are looking at.
You should also read the many great suggestions in this post.
I'm using Mongoid to store DateTime. But now i'm confusing with the real date.
In mongodb , the date is stored as:
{"2013-01-14T12:50:00.000Z"}
But when i print that value, it says:
2013-01-14T19:50:00+07:00
I don't really understand whether those Date formats are the same, and which one is "right" in my current timezone ?
Thank you for your help.
Date is stored in GMT, when "printed", it is displayed in your local timezone (GMT+7?)
The default Ruby date object should be able to handle offsets in time:
http://ruby-doc.org/stdlib-1.9.3/libdoc/date/rdoc/Date.html
Whereby some way down the page it even talks about how to start manipulating it I believe:
An optional argument the offset indicates the difference between the local time and UTC.
I do believe that mongoid is already converting the time for you as can be seen by the T value within the iso date being 7 hours ahead:
2013-01-14T19:50:00+07:00
Merely if you were to print the date and/or time instead of the full output with the offset included I have no doubt you will get the real date.
I believe mongoid most likely prints the offset even when it is applied because that offset IS there (since the time is off-setted by 7 hours from UTC) it is just not applied further.
I work in a large scale IT support environment. Twice now we have seen an invalid date of 02/31/2157 being inserted in an Oracle DATE column. So far I have not been able to reproduce this problem, but it appears to be happening occasionally when a user attempts to save '00/00/0000' into the column. I believe the value is originating from a PowerBuilder DataWindow update.
The application uses myriad libraries for all sorts of technologies, so this question may be a bit vague, but...
Has anyone seen the date 02/31/2157 in some established library that Oracle could be defaulting to when some other invalid date is entered? Perhaps an end-of-time concept analogous to the beginning-of-time date of 1/1/1970?
From http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/datatype.htm#i1847"
Oracle uses its own internal format to
store dates. Date data is stored in
fixed-length fields of seven bytes
each, corresponding to century, year,
month, day, hour, minute, and second.
2157-256 = 1901, which seems suspiciously close to a possible epoch of 1/1/1900 (or 12/13/1901 - which is the rollover date for the Year 2038 Problem)
I'd guess that it is storing either 0x00 or 0xFF in the date bytes, then getting confused when it decodes it. (How does it deal with month 255?)
Turns out this was a powerbuilder issue. The field was created in the datawindow as required, but was programmatically changed to be non-required before saving. So a null value was being saved to a non-null database column, and powerbuilder inserted some dummy date instead of just throwing an error.
I remember getting a weird value when saving an invalid date. IIRC it was in PB 9 and we had to get an EBF for it. It was a problem with Date Editmasks and entering an invalid date that wasn't rejected. Sorry I don't have more details.