I have to convert IST(India) to EET(Finland) timing using perl or shell ...
Means i have to subtract 3 hours,30 minutes from a given specific (ISD)time (not from the current time).
Time is in this format: YYYY-MM-DD HH:MM:SS
For ex: IST: 2016-01-01 02:30:00
Then after subtracting 3hours and 30 minutes ,I should get,
EET: 2015-12-31 23:00:00
The thing is after subtracting,if required the date,month and year should also change.
Can i do this using perl? Can anyone help me on this?
I'm not going to give you the actual code as you haven't demonstrated that you have made any effort to solve this yourself.
But the way to do this is to use a real Date/Time handling library. In Perl, that probably means DateTime. You can use DateTime::Format::Strptime to generate a DateTime object from a string.
In summary, your approach should be:
Parse your string into a DateTime object (being careful to ensure that the parsing object knows that the time zone is ISD (Icelandic time, I assume [Update: or, more likely, Indian]).
Convert the time zone in your parsed object to EET.
Use the parsed object's strftime method to produce the output time in the correct output.
Update: And I'll just add the standard advice about handling dates and times. You should always transmit and store dates and times in UTC. Local time zones should only every be displayed to users.
Related
We are defining a microservice that returns a timestamp in the combined date-and-time ISO 8601 format which is returned to our iOS client that's written in Swift. In our client, this is converted to a Date object.
The issue is one of the feeding sources of our microservice represents their date/times as two separate fields which we must combine into the complete ISO format. However, the time portion may be null so we have to substitute in 'T00:00:00Z'.
The problem is we need a way to communicate to the Swift side that the timestamp didn't have an original time value so it should be read in relative to GST, not the local timezone as one would normally do, and it should only ever be displayed in the UI as a date-only.
That said, what is the proper way to flag a Date object as being Date-only? Our current solution is a paired xIsDateOnly boolean on the model, but that just seems verbose. Does the Date object have any such mechanism/indication? I'm guessing not because a date without a time doesn't actually make sense as dates are based on 12am in a particular timezone, usually implied to be the one the user is in.
You're right, the Foundation (NS)Date object is really a timestamp, representing a specific moment in time. While it doesn't let you just specify a particular day, it does have the advantage of being the same no matter what calendar is in use.
To represent something like "June 3, 2014", you can use a DateComponents object. This lets you specify month, day, year, etc, without a time of day, relative to a particular calendar.
How do I get date function to return date according to current system date?
Right now, with the code snippet below, it always returns UK time, not the current system date.
<calculate>
<script>$ = concat( num2date(date(), DateFmt()), " ", num2Time(Time(), TimeFmt()) )</script>
Any help is appreciated!
It's probably not UK time exactly, but rather GMT (or UTC, to use a more precise term). The UK happens to be aligned to GMT in the winter, but in the summer it advances one hour to BST for daylight saving time.
Now, I've never used LiveCycle myself, but nonetheless, I've read through the somewhat minimal docs for LiveCycle FormCalc Date and Time Functions, and the spec, and it appears to me that a few critical mistakes were made.
The date and time functions return UTC-based values, but only the time-related functions have been made aware of the local time zone. That is, there are separate Num2Time and Num2GMTime functions, but there is only one Num2Date function.
The Num2Date function works in terms of whole integer days, and thus they are simply days since 1900-01-01. Therefore, the number being passed in to the function must already be representative of the desired time zone. However, the Date function only gets the current GMT date. There does not appear to be a function to get the current local date.
It's different on the time side, because of the millisecond precision involved. However, there's yet another flaw here. Despite the docs saying that the Time function returning "the number of milliseconds since the epoch", its actually returning only the number of milliseconds since midnight GMT. There is no day-over-day accumulation of milliseconds from the date part. The docs here are even lying in their sample code which says:
Returns the current system time as the number of milliseconds since the epoch.
Time() => 71533235 at precisely 3:52:15 P.M. on September 15th, 2003 to a user in the Eastern Standard Time (EST) zone.
If that was indeed the case (and ensuring to use their 1900-01-01 epoch), the value would actually include an additional 3272572800000 milliseconds representing the days between 1900-01-01 and 2003-09-15, bringing the total timestamp to 3272644333235. Additionally, there's a typo there, because the timestamp they give is 3:52:13, not 3:52:15. Clearly nobody paid close attention to these docs!
The real problem is that one cannot be certain that the number of milliseconds since midnight of the current day in the local time zone is the same on every day. If instead of getting the current time, you were working with past stored time values, you might be an hour off (+ or -) if the current offset is different due to daylight saving time. Example: Eastern time might be UTC-5 or UTC-4, but only the offset currently in effect will be used by the Num2Time function, even if the date you're working with is using the other offset.
So, in summary, the Date function is insufficient, leading to your observations, and the date/time functionality in general is poorly designed. Given the constraints of this API, I can't even recommend a workaround. There would have to be a LocalDate function of some kind to be used instead of the Date function, but it doesn't exist.
The only advice I can offer is that it appears (from my research, not experience) that LiveCycle can use either FormCalc or JavaScript. So - use JavaScript instead.
I am developing a plugin written in Lua, and I need a way to calculate Unix time or at least a way to compare 2 date strings.
The function I can use only returns date string in the following format
"1/17/2014 6:50 PM"
Is there a way to convert this string to a Unix time?
Unfortunately I don't have access to the OS library so things like os.time() do not work.
Is there any library or something similar that I can work with?
I also thought about splitting the string into parts, but I need a way to add/subtract time
Just compare normalized timestamps:
function normalize(a)
local m,d,y,h,mi,n=a:match("(%d+)/(%d+)/(%d+)%s+(%d+):(%d+)%s+(%w+)")
if n=="PM" then h=h+12 end
return string.format("%04d%02d%02d%02d%02d",y,m,d,h,mi)
end
Date arithmetic is another story. For a complete, pure Lua date library, see luatz or https://github.com/Tieske/date.
If you need to only compare two time, you don't need to get each time's Unix timestamp. One possible solution is to get the time fields from the string like this:
local time = "1/17/2014 6:50 PM"
local month, day, year, hour, minute, am_pm = time:match("(%d+)/(%d+)/(%d+)%s+(%d+):(%d+)%s+(%w+)")
print(month, day, year, hour, minute, am_pm)
Output: 1 17 2014 6 50 PM
Then compare two time from comparing their year, if they are equal, then month, and so on. Remember to use tonumber to compare them by number, not the string itself.
I am in the process of optimizing some UniVerse data access code we have which uses UniObjects. After some experimentation, it seems that using a UniSession.OConv call to parse certain things such as decimal numbers (most we have a MR4 or MR2 or MR2$) and dates (almost all are D2/) is extremely slow (I think it might make a call back to the server to parse it).
I have already built a parser for the MR*[$] codes, but I was wondering about the dates as they are stored so I can build one for D2/. Usually they seem to be stored as a 5 digit number. I thought it could be number of days since the Unix Epoch since our UniVerse server runs on HP-UX, but after finding '15766' as a last modified date and multiplying it by 86400 (seconds per day), I got March 02, 2013 which doesn't make sense as a last modified date since as far as I know that is still in the future.
Does anyone know what the time base of these date numbers are?
It is stored as a number of days. Just do a conversion on 0 and you will get the start date.
Edit:
As noted by Los, the Epoch used in UniVerse (and UniData) is 31st Dec 1967.
In Universe and any other Pick database, Dates and Times are stored as separate values.
The internal date is the number of days before of after 31/12/1967, which is day zero.
The internal time is the number of seconds after midnight. It can be stored as a decimal but is not normally.
In TCL there is a CDT command (stands for Convert Date) that converts dates from human readable to numeric and and vice versa:
CDT 9/28/2017
* Result: 18169
CDT 18169
* Result: 09/28/2017
I just want to clarify if I am understanding how dates & time zones work.
Basically, I have a date string #"2008-07-06 12:08:49" that I want to convert to an NSDate. I want this date and time to be in whatever the current user's time zone is set in. So if they are in GMT or HST, it's still 12:08:49.
If I have date in unix form 1215382129 (UTC) and my time zone is set to London (GMT), the outputted date from NSLog() is:
2008-07-06 12:08:49 +0100
If I then change my time zone to Hawaii (HST) and output the same date, I get:
2008-07-06 12:08:49 -1000
This seems to work fine, but I was under the impression to get the time in Hawaiian, I'd have to physically add the time difference (-10hrs) to the unix time stamp. Is this not required then?
Does that mean, whatever date and time a unix time is pointing to, it always points to the same date and time in whatever time zone a user is in?
Hope this makes sense!
Edit
I've just realised (thanks to Kevin Conner!) that in fact NSDateFormatter is creating different unix timestamps for that date string depending on the current timezone! So I was totally wrong!! :-)
Disclaimer, I'm mostly a Java guy. But Cocoa seems to work like the Java library in this regard: Dates are zoneless timestamps. Time zones are in the domain of formatting dates for display. In other words, the internal format doesn't consider time zones, it's all in UTC. Time zones are relatively a convenience for humans, so they are in the display/parsing side.
I noticed there is a setTimeZone: method on NSDateFormatter. Try calling that on your formatter before performing the format.