I would like to convert a yyyy-mm-dd to something like this:
"Saturday, 2 October 2009"
I would like also to have the option to modify the language both day of the week and month (make it customizable)
thanks in advance ;)
Since you never told us the language, here's a discussion on how to do it in COBOL.
Assuming .NET (from the datetime tag):
DateTime.Parse("2009-10-02").ToString("D", CultureInfo.CreateSpecificCulture("en"));
In C, you would use a combination of the localtime() and strftime() functions. They should handle internationalization more or less automatically, if your application is set up for it.
Convert the date into an integer, representing the days since a specific date, then add a number and apply the modulus operator with the operand 7. That will give you a number 0-6 that represents the day of week.
However, most languages have this functionality built-in.
Related
I have a variable DATE=2015-02-08. I want a variable NEXT_DATE which will store a date value 1 day after this $DATE value.Thanks in advance.
You could convert the date to a Julian Date, add 1, then convert back. Due to the nature of our calendar, this is a bit involved (at least for shell arithmetic). Should the Wikipedia article not be enough, the calulations are explained here.
You cold try to convert that time-stamp in UNIX time, add 3600*24 seconds to it, and then convert it back again to your format.
Can someone help me tell what datetime format is this, or what are it's parts?
e.g.
201106020539Z0000031552001001
201106020702Z0000000000001
201105140701Z0000000000001
201105170207A0000018560001001
I think I've got the first few parts (201106020539 is yyyymmddhhmm), but from the Z / A character onward, I have no clue. Is it possible that the rest isn't a datetime at all?
The Z implies Zulu or UTC time https://meta.stackexchange.com/questions/14684/so-html-formats-time-incorrectly, as for what comes after, I don't know since all other time data has already been indicated prior to the Timezone Character.
Also, the fact that your timestamps don't seem to end in the same number of characters suggests they might not be the same format/spec? Where did you obtain them?
In which context did you get these strings? I would guess that the digits are the seconds fractions.
Maybe this helps you:
For a UTC time (a DateTime.Kind
property value of DateTimeKind.Utc),
the result string includes a "Z"
character to represent a UTC date.
I exported my Firefox bookmarks, and the 'dateAdded' fields look like this:
1260492675000000
1260492675000000
1266542833000000
They're too big to be a Unix timestamp, and I can't make sense of them. What are they? (I want to convert it into something usable/readable.)
It is PRTime.
This type is a 64-bit integer representing the number of microseconds since the NSPR epoch, midnight (00:00:00) 1 January 1970 Coordinated Universal Time (UTC). A time after the epoch has a positive value, and a time before the epoch has a negative value.
PRTime as described on this page.
You can extract the time using the f3e tool if you can find a link to it.
In SQL Server Reporting Services, how would I calculate the last day of the current month?
Here is the answer I came up with
=DateSerial(Year(Now()), Month(Now()), "1").AddMonths(1).AddDays(-1)
As it took me a while to Figure this out, and JC's answer was the simplest to modify and had a good logical structure. I expanded it Slightly for others searching for answers on this topic.
I have found normally you don't just want the Last Day of a month / year you also want the first day of the month / year. So here they are the full lines to calculate just that. wtih the SQl version there also.
First Day of Current month
SSRS=Today.AddDays(1-Today.Day)
SQL=SELECT DATEADD(s,0,DATEADD(mm, DATEDIFF(m,0,getdate()),0))
Last day of Current Month
SSRS=Today.AddDays(1-Today.Day).AddMonths(1).AddDays(-1)
SQL=SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+1,0))
First Day of Current year
SSRS=Today.AddMonths(1-Today.month).AddDays(1-Today.day)
SQL=SELECT DATEADD(yy, DATEDIFF(yy,0,getdate()), 0)
Last Day of Current Year
SSRS=Today.AddDays(1-Today.Day).AddMonths(13-today.month).AddDays(-1)
SQL=SELECT DATEADD(dd,-1,DATEADD(yy,0,DATEADD(yy,DATEDIFF(yy,0,getdate())+1,0)))
I hope this helps somone.
I know you've found your own answer, but I'd suggest this alternative:
=Today.AddDays(1-Today.Day).AddMonths(1).AddDays(-1)
It's a little easier to read, in my opinion, and might have slightly better performance (though most likely unnoticeable)
And, of course, if you wanted to pad out that date to 23:59:59, as is often necessary, just modify slightly:
=Today.AddDays(1-Today.Day).AddMonths(1).AddSeconds(-1)
From the blog of a Microsoft SQL Team member:
-- returns the last day of the current month.
select dbo.Date(year(getdate()), month(getdate())+1,0)
http://weblogs.sqlteam.com/jeffs/archive/2007/01/02/56079.aspx
Hope this helps!
--Dubs
You may try this expression, Just replace now with your date field.
=DateSerial(Year(Now), Month(Now), 1)
Hope this helps.
Regards
There is an even easier way as in the marked answer:
=DateSerial(Year(Now()), Month(Now())+1, 0)
Since DateSerial() accepts integers as parameters one does not have to use AddMonths() and AddDays(). As in the example an instant calculation inside DateSerial() is possible.
Furthermore day 1 is the first day of the month while the first day minus one day is the last day of the month before (1-1=0). So the example will return the date of the last day of the current month.
you can use an assembly for doing this work by adding it as a reference.
Dates in DB2 AS/400 are an integer, containing the number of days since sometime around the turn of the 20th century.
Question 1: Does anyone know the IBM DB2/AS400 "zero" date? e.g.:
12/30/1899
12/31/1899
1/1/1900
Question 2: Given an "AS/400" date (e.g. 40010) how can you convert that to a CLR DateTime?
DateTime d = new DateTime(40010); //invalid
Some other "zero" dates are:
OLE Automation: 12/30/1899
SQL Server: 1/1/1900
I don't think AS/400 dates are stored internally as some number of days from an epoch date1 (this is the more common term for what you are calling "zero date"). As Tracy Probst said, this is definitely NOT what date fields in native AS/400 physical files look like.2
But that's immaterial if whatever method you are using to extract the data is giving it to you as the number of days since an epoch. Ideally, you should find out what the intended date is by looking directly at the AS/400, or asking someone who can. If the date on the AS/400 is 2009-07-30 and what you are getting is 40022, then you can be pretty confident the epoch date is Jan 1, 1900. If you are getting 40024, then the epoch is Dec 30, 1899. (Though it's of course best to compare a bunch of dates, preferably from different years to guard against possible use of Julian dates.)
Also, as Tracy commented on his own answer, it's exceedingly common for dates to be stored in generic numeric fields (which is what I would guess if your retrieval method is reporting Decimal as the data type), in which case it really has nothing to do with DB2's internal date format anyway. You should be aware that by far the most common date formats stored in AS/400 numeric fields are the following, or variations thereof:
yyyymmdd (Gregorian, ISO 4-digit year)
mmddyy (Gregorian, U.S. 2-digit year)
yyyyddd (so-called Julian, 4-digit year)
yyddd (so-called Julian, 2-digit year)
yymmdd
cyymmdd (IBM's crazy invention with century flag)
The ddd in the Julian dates is the number of days from the beginning of year. The c in IBM's crazy date is 0 for 19yy or 1 for 20yy. I have not heard of anyone who stores days-since-epoch on "The Four Hundred" but maybe you've encountered a convert from another platform. The mainframe heritage of the AS/400 strongly favors human-readable dates.
1The AS/400 (now called IBM i) does have its own data type for dates, and this data type actually does consist internally of a number of days from an epoch. But that epoch is many thousands of years in the past, not somewhere near the turn of the 20th century, and not even near the beginning of the Common Era. IBM likes to call this number of days the Scaliger number, but for most people who study this stuff, it's called the Julian Day Number. As you may have noticed from the main part of my answer, IBM uses the word "Julian" to mean something completely different (and not even related to the Julian calendar). Namely, IBM's so-called "Julian date" is really the ordinal date from ISO 8601.
2The internal format of the date data type is very low-level and mostly hidden from the user (including most programmers). The DSPPFM command, which ostensibly shows the "actual contents" of a file, is at least one step "too late": the value it reports has already been converted from the internal, 4-byte "Scaliger number" to a human-readable form.
Question 1:
I have no idea what the start date is for DB2. Google isn't very helpful anyway. Don't you have any sample data you could use to figure it out?
Update: are you sure the date is stored as a number of days? I found this page that suggests otherwise.
Question 2:
Assuming 1900-01-01 as the start date in this example, where days is the AS/400 date value.
DateTime myDate = new DateTime(1900, 1, 1).AddDays(days);
I don't know the answer for 1. But for 2, you can do something like this:
private DateTime AS400 = new DateTime(1900, 1, 1);
...
DateTime myClrDT = AS400.AddDays(days);
Question 1:
As far as I can tell, there is no "zero date" in an AS/400 phsyical file. If I do a DSPPFM on a phsyical file with a timestamp field in it, the value is stored as a readable timestamp in the format yyyy-MM-ddhh.mm.ss. For example: "2005-08-0207.06.33" for 08/02/2005 at 7:06:33 AM. There can be a zero-date within a particular programming language and that's really where you need to focus. The AS/400 ODBC driver returns the date in a SQL_TYPE_TIMESTAMP field.
Question 2:
It should be as simple as:
DateTime d = Convert.ToDateTime(reader["DateField"]);
I invite other C# experts to edit the response with better C# code.
I've just 5 months of experience in DB2(working on AS400), so i just can show you something
about the way we work with dates. It's true that we consider the 'zero' date in our calculation of the date fields. In our system, the 'zero' date =12/31/1971 0:00.
I don't know if this is the 'only' 'zero' date in AS400.
In our system files, the date we use is stored as the number of days from the 'zero' date(length=5).
So, every time we have to get the date field, from a specified file, we convert this field to get the date in the format : dd/mm/yyyy or yyyy-mm-dd(it depends from the environment where we execute the query). The function is:
date(field+719892), where field is the field where we store the date and 719892 is the number of days we add after each unconverted date we use(it seems like it is the number of days between x-12/31/1971, you can calculate x).
I'll give you on more example:
select date(15+719892) as date1 from library1.file1
The result is: date1=1972-01-15
marc_s had a comment that confused the "zero" dates with "minimum" dates in SQL Server. Just so everyone gets to see the example:
SELECT
CAST(0 AS datetime) AS dateTimeZero,
CAST(0 AS smalldatetime) AS smallDateTimeZero
dateTimeZero smallDateTimeZero
======================= ===================
1900-01-01 00:00:00.000 1900-01-01 00:00:00