In my json date is represented like this :-
"from":"2015-11-11T09:21:00.00Z"
But when it gets converted to java.sql.Timestamp it looks like this :-
2015-11-11 17:21:00.0
My timezone is Singapore . It is 8 hours ahead of UTC timezone and coincidentally the date also gets converted to 8 hours ahead of its time.
They are showing the same times, just formatted differently for the different locations. The time you are taking in is UTC/GMT. What you are viewing in your IDE is showing the local time stamp formating, but they are the same values and points in time.
If it really matters how it is displayed to you in the debugger you can use a Calendar object instead of a TimeStamp and set the locale value to be UTC and it will format them the same way, but again they are the same values.
I don't want the Timestamp in java to be different from json
It is not different, the display format is different do to the location setting but they are the same values just represented differently.
P.S. Be aware that if your server is set to a different time zone than your work station it will show a different format as well, but it again will be the same time just represented differently.
Related
I have a column in my database that is of type DATE.
I inserted the date via Java using the method: Date.valueOF(LocalDate.now()).
r.setRkd(Date.valueOf(LocalDate.now()));
The entry is correct because the exact date appears in the table.
rkd
------------
2022-03-02
The problem is that when I call the service I don't get the correct date back in the JSON, but a series of numbersenter code here.
"rkd": 1646175600000
Do you know how I can print the correct date in my JSON?
Thank you in advance.
That number you are getting is the milliseconds equivalent to the date you have stored. As far as I know, dates, in general, are stored as milliseconds and displayed in different formats, e.g. YYYY-MM-DD
If you need to display it in date format there should be a method to do it depending on the specific language that you're using.
I'm using openweather 3hours forecast api. Why does the date show only the same time? even though values are different? date is supposed to be every three hours. I formatted the date in weatherItem.dart after iterating over each item.. how can I get the date with every three hours and render on the screen?
Looking at the JSON data you provided with the dt_txt key, you'll find that the date format does not contain time. So the JSON data you're getting does not contain a valid time you can use
I am working on a webrequest, and the last part of it is (for exemple) :
...&cb=jQuery1702547129448580113_1468872275121
I was sure this relies to the DateTime the Get request is send to the server, and 1468872275121 indeed is 18/07/2016 20:04:35 UTC (converted from Json/Unix date format).
Ok good.
But any idea what could be the first part ?? Is it also a DateTime value ? (the request is sent when adding some item to your cart on a commercial site)
Thanks!
The default for dates in JSON is a string in RFC 3339 or IS 8601 format, like "2012-04-23T18:25:43.511Z". You will also find dates stored as a number storing either seconds or milliseconds since midnight, Jan 1st. 1970 in UTC.
A year has about 30 million seconds. Compare that with the number that you see.
I would like to ask how to add datetime ('Y-m-d h:i:s') format field for the SQL.
The name of my table is groups, the name of the field is date_add
i am using cake PHP 3, i want to use the timezone Australia/Perth but i don't know how to begin.
I successfully displayed added my date using
$group->date_add = date("Y-m-d h:i:s");
However, the result for the time is not correct with the timezone.
Datetime in PHP in general
Per the documentation of DateTime you can use all options available for the date() functions for formatting. Your main mistake in the formatting is the difference betweetn a y and a Y being the difference between a year in two and a year in four numbers.
Secondly you say you want to add the correct time zone. This is a bit odd however since you always want to add the same time zone. If you want to convey the fact that all your dates are Australia/Perth as information why do you not simply add that text after it?
If you mean this is a problem since you store the information in a different time zone to begin with and thus have a conversion problem you can set the correct time zone on the DateTime object itself. But you need to be sure the DateTime object is constructed with the correct original time zone to begin with. Observe the following code for an explanation:
<?php
$DateTime = new DateTime(); // This is now Europe/Amsterdam for my laptop
var_dump($DateTime->format('dmY h:i e'));
// result of var_dump is: string(31) "13102015 12:00 Europe/Amsterdam"
$DateTime->setTimeZone(new DateTimeZone('Europe/London'));
var_dump($DateTime->format('dmY h:i e'));
// result of var_dump is: string(28) "13102015 11:00 Europe/London"
Take aways:
e is the format modifier for the time zone
Conversion of time zones is possible with PHP's DateTime object. Find out what your default time zone is on your current PHP installation to see if you need to convert or not. See information on the date.timezone setting here: http://php.net/manual/en/datetime.configuration.php
Cake 3.0 specific
As Oops D'oh pointed out in the comments there are a lot of CakePHP specific things to know as well. Since he added an excellent part concerning that I suggest you read that as well.
I'm using Access 2003. Have a table with some date values in a text data column like this;
May-97
Jun-99
Jun-00
Sep-02
Jan-04
I need to convert them to proper date format and into another Date/time column, So create a new Date/Time columns and just updated the values from the Text column into this new column. At first it looked fine, except for years after the year 2000. The new columns converted the dates as follows;
May-97 > 01/05/1997
Jun-99 > 01/06/1999
Jun-00 > 01/06/2000
Sep-02 > 01/09/2010
Jan-04 > 01/01/2010
As you can see any data with year after 2000 get converted to 2010. The same thing happens if I query the data using FORMAT(dateString, "dd/mm/yyyy").
Any ideas why this is so? Do I have to split the month and year and combine them again?
Thanks
Access/Jet/ACE (and many other Windows components) use a window for interpreting 2-digit years. For 00 to 29, it's assumed to be 2000-2029, and for 30-99, 1930-1999. This was put in place to address Y2K compatibility issues sometime in the 1997-98 time frame.
I do not allow 2-digit year input anywhere in any of my apps. Because of that, I don't have to have any code to interpret what is intended by the user (which could conceivably make mistakes).
This also points up the issue of the independence of display format and data storage with Jet/ACE date values. The storage is as a double, with the integer part indicating the day since 12/30/1899 and the decimal part the time portion within the day. Any date you enter is going to be stored as only one number.
If you input an incomplete date (i.e., with no century explicitly indicated for the year), your application has to make an assumption as to what the user intends. The 2029 window is one solution to the 2-digit year problem, but in my opinion, it's entirely inappropriate to depend on it because the user can change it in their Control Panel Regional Settings. I don't write any complicated code to verify dates, I just require 4-digit year entry and avoid the problem entirely. I have been doing this since c. 1998 as a matter of course, and everybody is completely accustomed to it. A few users squawked back then, and I had the "it's because of Y2K" as the excuse that shut them down. Once they got used it, it became a non-issue.
The date is ambiguous, so it is seeing 02 as the day number. Depending on your locale, something like this may suit:
cdate("01-" & Field)
However, it may be best to convert to four digit year, month, day format, which is always unambiguous.
Access seems to be get conduced between MM-YYYY format and MM-DD format. Don't know why it is doing it for dates after the year 2000, but solved it by converting the original string date to full date (01-May-01). Now Access converts the year into 2001 instead of 2010.
If you don't supply a year and the two sets of digits entered into a date field could be a day and month then Access assumes the current year. So your first three dates definitely have a year in them. But the last two don't.
Note that this isn't Access but actually the operating system doing the work. You get the same results in Excel. I had an interesting conversattion with some Microsoft employees on this issue and it's actually OLEAUT32.DLL.