There's an iOS app that I'm looking at where the SQLite table for date shows up as the following
ZRECORDDATE
423942471
423873218
423512431
423950419
423954082
423954975
424551647
at first I believe it was UNIX time but after using a converter - 1983 definitely isn't it.
I'm probably missing the obvious here but can anyone point me in the right direction for converting this to a human date/time?
Thanks in advance
With your indication, it may be a time interval since 01 Jan 2001 in seconds.
let sec : TimeInterval = 423942471
let date=Date(timeIntervalSinceReferenceDate:Sec)
print("date \(date)")
Related
I am trying to learn F# and was wondering if i have a json object which has time in microseconds as int. I want to get the day, date and time out of this and was wondering how to do it.
I actually happen to have needed to do this recently. You'll almost certainly want to use the .NET time objects (DateTime, DateTimeOffset, TimeSpan) in some capacity. Here's what I went with:
let TicksPerMicrosecond =
TimeSpan.TicksPerMillisecond / 1000L
let FromUnixTimeMicroseconds (us: int64) =
DateTimeOffset.FromUnixTimeMilliseconds 0L + TimeSpan.FromTicks(us * TicksPerMicrosecond)
From TimeSpan.TicksPerMillisecond we can calculate how many are in a microsecond (if I remember correctly it's 10, but this way it doesn't seem as "magic"). Then I can convert the microseconds value into ticks and add it to the epoch date.
To get the day of the week (assuming the time zone is UTC), you'd just use DateTimeOffset.DayOfWeek.
I am unable to understand the expiry date format of the JWT embedded in my application.
For example: 1473912000
What does this translate to? 1473912000 ms, some x date? Any help will be appreciated!
Like James has pointed out:
The number is the number of seconds since Jan 1 1970.
This is converted into the Date object in a quite straight-forward way (the *1000 part is here because in JS main time unit is millisecond):
const expiryDate = new Date(1473912000*1000);
Then you can use any Date method you please.
Likewise, in Ruby you can use Time.at(1473912000) to create a new Time instance like Maxim has shown.
The number is the number of seconds since Jan 1 1970. It is commonly used on unix systems to represent time. Your time is 2016-09-15 04:00 (UTC)
To convert you can try a web based system http://www.unixtimestamp.com/index.php
This is UNIX time in seconds:
➜ ~ irb
2.2.0 :001 > Time.at(1473912000)
=> 2016-09-15 07:00:00 +0300
Two computer install centos 6.5, kernel is 3.10.44, have different result.
one result is [u'Asia/Shanghai', u'Asia/Urumqi'], and the other is ['Asia/Shanghai', 'Asia/Harbin', 'Asia/Chongqing', 'Asia/Urumqi', 'Asia/Kashgar'].
Is there any config that make the first result same as the second result?
I have following python code:
def get_date():
date = datetime.utcnow()
from_zone = pytz.timezone("UTC")
to_zone = pytz.timezone("Asia/Urumqi")
date = from_zone.localize(date)
date = date.astimezone(to_zone)
return date
def get_curr_time_stamp():
date = get_date()
stamp = time.mktime(date.timetuple())
return stamp
cur_time = get_curr_time_stamp()
print "1", time.strftime("%Y %m %d %H:%M:%S", time.localtime(time.time()))
print "2", time.strftime("%Y %m %d %H:%M:%S", time.localtime(cur_time))
When use this code to get time, the result of one computer(have 2 results) is:
1 2016 04 20 08:53:18
2 2016 04 20 06:53:18
and the other(have 5 results) is:
1 2016 04 20 08:53:18
2 2016 04 20 08:53:18
I don't know why?
You probably just have an outdated version of pytz on the system returning five time zones (or perhaps on both systems). You can find the latest releases here. It's important to stay on top of time zone updates, as the various governments of the world change their time zones often.
Like most systems, pytz gets its data from the tz database. The five time zones for China were reduced to two in version 2014f (corresponding to pytz 2014.6). From the release notes:
China's five zones have been simplified to two, since the post-1970
differences in the other three seem to have been imaginary. The
zones Asia/Harbin, Asia/Chongqing, and Asia/Kashgar have been
removed; backwards-compatibility links still work, albeit with
different behaviors for time stamps before May 1980. Asia/Urumqi's
1980 transition to UTC+8 has been removed, so that it is now at
UTC+6 and not UTC+8. (Thanks to Luther Ma and to Alois Treindl;
Treindl sent helpful translations of two papers by Guo Qingsheng.)
Also, you may wish to read Wikipedia's Time in China article, which explains that the Asia/Urumqui entry is for "Ürümqi Time", which is used unofficially in some parts of the Xinjiang region. This zone is not recognized by the Chinese government, and is considered a politically charged issue. As such, many systems choose to omit the Urumqi time zone, despite it being in listed in the tz database.
I have a org.threeten.bp.LocalDate and a org.threeten.bp.LocalTime and I do need a java.util.date instance. Whats the best way to archieve this. I looked through DateTimeUtils but found no proper solution.
Here is the better solution without using deprecated stuff but using the helper class DateTimeUtils:
// your input (example)
LocalDate date = LocalDate.of(2015, 4, 3);
LocalTime time = LocalTime.of(17, 45);
// the conversion based on your system timezone
Instant instant = date.atTime(time).atZone(ZoneId.systemDefault()).toInstant();
Date d = DateTimeUtils.toDate(instant);
System.out.println(d); // Fri Apr 03 17:45:00 CEST 2015
You need a timezone to make this conversion working. I have chosen the system timezone in the example given above but you are free to adjust the timezone to your needs.
Life can be so easy:
Date date = Date(localDate.year,localDate.monthValue,localDate.dayOfMonth,localTime.hour,localTime.minute, localTime.second)
edit: oh wait.... this is deprecated! So another solution would be better!
I live in Denmark (UTC + 1 ) and I am working with a webapi that sends my app a unix timestamp since 1970-1-1 00:00:00. The time is in the future (train depatures)
If I check the timestamp in Numbers or Excel it gives me the correct time
To calculate the number of minutes until the train departures I do like this:
let unixTimeTrainDeparture = 1419327780 //(or some time in the future)
let unixRightNow = NSDate().timeIntervalSince1970
let minutesToDeparture = (Int(unixTimeTrainDeparture) - Int(unixRightNow))/60
However this gives 60 minutes too much?
And If I do a
let dateTest = NSDate(string: "1970-01-01 00:00:00 +0000")!
will give me 1 jan 1970 :01:00:00 +0000
This does not make sense to me. It is like the timeIntervalSince1970 gives me 3600 sec too less, as it starts from 1970-1-1 01:00 rather than 00:00? It this a bug or is it the way it should be?
I can correct the time by using the
let tz = NSTimeZone.defaultTimeZone()
let seconds = tz.secondsFromGMTForDate(NSDate())
and then subtracting the seconds from my result. However, what happens when we move into summer time?
timeIntervalSince1970 always gives the time in GMT. Your unixTimeTrainDeparture is probably the time in GMT+1, which explains the 60 minute difference (or 120 minutes in summer time). Same goes with the string conversion - you input a GMT time and it outputs the date in whatever timezone you have configured (I'm guessing your computer's setting is GMT+1 as well).
When working with timezones, always start with GMT/UTC and don't do any timezone conversions until displaying the date to the user.
Do you have any control over the web API? If so - configure it to send GMT instead. This should completely avoid time zone and daylight savings issues.
If you cannot do that you will have to implement some function to convert the timestamp yourself, accounting for the possibility that a future timestamp could be in a different timezone (eg daylight savings). NSTimeZone might be very useful for this!
Hope I have understood your problem correctly!
Edit, added example that should handle DST:
// Date far in the future in DST, replace this
let unixTimeTrainDeparture = NSDate(timeIntervalSince1970: 1436447418)
let now = NSDate()
// Assume unixTimeTrainDeparture is in the Copenhagen timezone
let tz = NSTimeZone(name: "Europe/Copenhagen")
// This is 3600 in non-DST, otherwise 7200
let offset = tz!.secondsFromGMTForDate(unixTimeTrainDeparture)
let realUnixTimeTrainDeparture = Int(unixTimeTrainDeparture.timeIntervalSince1970) - offset
let timeToDeparture = realUnixTimeTrainDeparture - Int(now.timeIntervalSince1970)