Background
I get the following date back from the system:
>print(os.date("%d.%m.%y.%c"))
30.11.16.Wed Nov 30 15:39:11 2016
I am trying to figure out how to convert the time so I get back 10:39:11 instead of 15:39:11
So far as a test, I've tried this:
> print(os.date("%I"))
03
and
> print(os.date("%d.%m.%y %I"))
30.11.16 03
>
Question
I guess I don't understand why I'm getting back "03".
What I've Tried
I tried to set the locale information using
os.setlocale('en')
and then retried the os.date command but it's still returning the 03.
Can you tell me what the 03 represents, as well as how I can get back the current time for my time zone (Eastern) and in a 12 hr format?
Thanks.
You are getting 03, because as it states in the Corona docs:
%I: Hour in 12-hour format (01 – 12)
I'd recommend you check what timezone you are getting using %z. Also read that piece of documentation, as all the information you need is there.
Related
Im in east 8+ timezone, and this expression return nil on my device.
I know it returned a value counting my timezone infomation. But, Why? I don't get it. How this function implemented and what puporse of it?
Thanks.
Implemention can be found here: https://www.lua.org/source/5.1/loslib.c.html#os_time
os.time is equivalent to mktime in C, the result of the function is dependent on the OS lua is running on.
On Windows, it returns -1 if the local date is before 1970-1-1 UTC. That's why you got nil. (Since Lua 5.3, it throws an error instead). If you call this function on *inx system you can get a negative number.
I am using on Linux often Minus Epoch' for formating Dates/Timelines with os.date()
( My Birthday is before 1970 :-O )
Also os.setlocale()...
> os.setlocale('de_DE.UTF-8', 'time')
de_DE.UTF-8
> os.date('%c', os.time({year=1970, month=1, day=1, hour=0}))
Do 01 Jan 1970 00:00:00 CET
> os.date('%c', os.time({year=1945, month=8, day=6, hour=0}))
Mo 06 Aug 1945 00:00:00 CEMT
> os.date('!%c', os.time({year=1945, month=8, day=6, hour=0}))
So 05 Aug 1945 21:00:00 GMT
> os.setlocale('ja_JP.utf8', 'time')
ja_JP.utf8
> os.date('%c', os.time({year=1945, month=8, day=6, hour=0}))
1945年08月06日 00時00分00秒
I am using DatePipe to display Epoch time, the milliseconds time is in UTC, I want to keep it display on UTC so I am setting timezone option is '0'.
Here is my code:
<span class="description">{{epochTime | date:'dd/MM/yy hh:mm a':'0'}}</span>
with 'epochTime' = '1570274515223' <=> 'Sat Oct 05 2019 11:21:55 AM'.
But on the UI is: '05/10/19 06:21 PM'
It is getting local time zone here. Why I can not force pipe to use UTC time?
'0' is not valid. Instead, specify the offset in one of the following ways: 0, '+0','+00:00', 'UTC'
I was playing time arithmetic in rails console. I have subtracted two different times and got back a long number, please see below my code.
a = User.find(1).updated_at # returns Mon, 03 Mar 2014 11:07:43 UTC +00:00
b = User.find(1).created_at # returns Mon, 03 Mar 2014 08:36:50 UTC +00:00
a - b # returns 9053.699814796448
My question is. What is this number 9053.699814796448? Is it time? What is it's unit? and how is that calculated? Is it possible to change the default unit of the outcome?
Thanks
a - b gives you the time in seconds. Check out the Time#- .
I see that typing 100.days gives me [edit: seems to give me] a Fixnum 8640000:
> 100.days.equal?(8640000)
=> true
I would have thought those two values were interchangable, until I tried this:
x = Time.now.to_date
=> Wed, 31 Oct 2012
> [x + 100.days, x + 8640000]
=> [Fri, 08 Feb 2013, Mon, 07 May 25668]
Why, and how, does adding apparently equal values to equal dates give different results?
The above results are from the Rails console, using Rails version 3.1.3 and Ruby version 1.9.2p320. (I know, I should upgrade to the latest version...)
100.days doesn't return a Fixnum, it returns an ActiveSupport::Duration, which tries pretty hard to look like a integer under most operations.
Date#+ and Time#+ are overridden to detect whether a Duration is being added, and if so does the calculation properly rather than just adding the integer value (While Time.+ expects a number of seconds, i.e. + 86400 advances by 1 day, Date.+ expects a number of days, so +86400 advances by 86400 days).
In addition some special cases like adding a day on the day daylight savings comes into effect are covered. This also allow Time.now + 1.month to advance by 1 calendar month irrespective of the number of days in the current month.
Besides what Frederick's answer supplies, adding 8640000 to a Date isn't the same as adding 8640000 to a Time, nor is 100.days the correct designation for 100 days.
Think of 100.days meaning "give me the number of seconds in 100 days", not "This value represents days". Rails used to return the number of seconds, but got fancy/smarter and changed it to a duration so the date math could do the right thing - mostly. That fancier/smarter thing causes problems like you encountered by masking what's really going on, and makes it harder to debug until you do know.
Date math assumes day values, not seconds, whereas Time wants seconds. So, working with 100 * 24 * 60 * 60 = 8640000:
100 * 24 * 60 * 60 => 8640000
date = Date.parse('31 Oct 2012') => Wed, 31 Oct 2012
time = Time.new(2012, 10, 31) => 2012-10-31 00:00:00 -0700
date + 8640000 => Mon, 07 May 25668
time + 8640000 => 2013-02-08 00:00:00 -0700
date + 100 => Fri, 08 Feb 2013
It's a pain sometimes dealing with Times and Dates, and you're sure to encounter bugs in code you've written where you forget. That's where the ActiveSupport::Duration part helps, by handling some of the date/time offsets for you. The best tactic is to use either Date/DateTime or Time, and not mix them unless absolutely necessary. If you do have to mix them, then bottleneck the code into methods so you have a single place to look if a problem crops up.
I use Date and DateTime if I need to handle larger ranges than Time can handle, plus DateTime has some other useful features, otherwise I use Time because it's more closely coupled to the OS and C. (And I revealed some of my roots there.)
I need to store some time periods in a yaml file, like this:
test:
testing: <%= 1.month %>
I grab the data in an initializer like this:
Class::TIMES = YAML.load(ERB.new(File.new(Rails.root.join('config', 'times.yml')).read).result)
So far so good. But the times I get from this are always off by a day; testing shows this. For example:
<Tue, 06 Mar 2012> expected but was <Wed, 07 Mar 2012>.
The test line:
assert_equal 1.month.from_now.to_date, #object.finished_at.to_date
Elsewhere, #object's finished_at is set like this:
# duration is from the YAML file
self.finished_at = duration.from_now
It always seems to be off by a day, no matter what time period I put in the YAML file. Why does this happen?
EDIT: This seems to be an issue with Fixnums and from_now:
> 1.month.from_now
=> Tue, 06 Mar 2012 21:05:00 UTC +00:00
> 1.month.to_i.from_now
=> Wed, 07 Mar 2012 21:05:05 UTC +00:00
When you convert 1.month to an integer it arbitrary sets the duration getting passed into from_now to 2592000 seconds i.e 30 days regardless of what month it is.
I ran into this issue once before. Check out the documentation for the Data and Time Helper Methods .
While these methods provide precise calculation when used as in the
examples above(".. 1.month.from_now .."), care should be taken to note
that this is not true if the result of months’,years’, etc is
converted before use