Calling an API, I need to specify time in milliseconds. I use DateTime in Python 3 to convert from and to human readable dates and times. But when debugging, I get different results depending on what website I use to convert, so I'm having a hard time debugging when the timestamps are (maybe) wrong. The API doesn't combine time and date in their predicates, but uses milliseconds for both.
Let's look at the date predicate 1656547200000
If I go to https://currentmillis.com it says it's June 30th. All good.
If I go to https://www.epochconverter.com it says it's June 30th. All good.
Let's look at the time predicate from 12600000 to 26700000.
12600000, 26700000
If I go to https://currentmillis.com it says it's UTC (24h) 03:30 - 07:25
If I go to https://www.epochconverter.com it says it's UTC (24h) 20:00 - 00:40
Why that different results?
Historically, UNIX systems reckon time as temporal units (seconds, millis, nanos, etc.) elapsed since an absolute origin instant termed "the Epoch": January 1st, 1970 00:00:00 UTC. This is formally recognized in POSIX.
So "UNIX time" is that system of reckoning, and "Epoch timestamps" are points in time in that system.
Now, you appear to me to be conflating temporal units in your use of Epoch timestamps.
In the case of your "short" timestamp, 12600000 seconds since the Epoch is a different point in time than 12600000 milliseconds since the Epoch. That's why you see them resolve to different times of day, as your converters are interpreting them differently. If you'd included the date in your output, you'd have seen the two points in time are almost six months apart.
I have a dataset file with a time variable in "seconds since 1981-01-01 00:00:00". What I need is to convert this time into calendar date (YYYY-MM-DD HH:mm:ss). I've seen a lot of different ways to do this for time since epoch (1970) (timestamp, calendar.timegm, etc) but I'm failing to do this with a different reference date.
One option is to simply add 347133600s (11 years) to each value in seconds. this will then allow you to simply use conversion as it would be from 1970-01-01.
I'm trying to convert java datetime instant to hh:mm format using moment js
moment("2020-03-21T17:34:00Z").utcOffset(-0500).format("hh:mm")
it should give me 12:34, but somehow it is giving "12:14" which is the wrong time.
The moment js .utcOffset() method takes the offset in minutes.
so if you want to get 12:34 you need to use -300 instead of -0500
moment("2020-03-21T17:34:00Z").utcOffset(-300).format("hh:mm")
A few things:
The utcOffset function behaves differently whether you pass a string or a number. As a number, it's expected to be in terms of minutes. Since you have hours and minutes in your offset, you should pass it as a string: .utcOffset("-0500")
Format strings are case sensitive. You should use HH:mm (24-hour time), or hh:mm a (12-hour time). Since you used hh:mm without an a, anything after 12 pm will be misrepresented.
You are supplying a fixed offset. If that is your intent, then ok. But do recognize that there is a difference between an offset and a time zone. (See "Time Zone != Offset" in the timezone tag wiki.) For example, if you wanted to convert to US Eastern Time, you should use .tz('America/New_York) instead of .utcOffset("-0500"). (US Eastern time is at -4 for the date given, not -5.) You would need the moment-timezone addon to make this work.
Lastly, recognize that Moment is in maintenance mode. The moment team generally recommends Luxon for new development.
How does timezones works in javascript?
I'm trying to use moment.js but have some strange results.
In my zone moment().format() returns 2014-08-05T18:56:08+02:00.
But this one moment(0).format() returns 1970-01-01T01:00:00+01:00.
Why do the timezones differ?
You see the timezone differences due to the Daylight Saving Time (or Summer Time).
On moment=0 you timezone was not in DST so the offset by that time was +1 (I believe this is the normal offset in your region).
Right now, in the current moment you use moment(), your region is in DST so your current offset is +2. That's why you see the different offsets.
I've never used Javascript, but using google I found this link.
It looks like passing 0 as an argument constructs a time with a 0 millisecond offset from the start of Unix Time.
If we go 0 milliseconds from the start of unix time, we end up at the start of unix time. Which is Thursday, 1 January 1970.
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