How can I validate date before 1970-01-01 (like 1900-01-01)?
When I try to use CDateVaildator it ends with CTimestamp::getTimestamp() (I found it with help of debugger)
return #mktime($hr,$min,$sec,$mon,$day,$year)
where $hr=0, $min=0, $sec=0, $mon=1, $dat=1, $year=1900 which obviously returns false and this fails whole validation.
CTimestamp::getTimestamp() will generate a timestamp for any dates from 1901 (not 1900!) up to 2038. For dates between 1901 and 1970 it generates a negative number. Just tested it, and the earliest date I can get to work is 14th December 1901. Anything before this throws an error. Not sure how to deal with dates outside this range!
In Yii there is an error described here. The solution is presented there but for some reason it's not included in Yii 1.1.14 although it's marked as committed to trunk.
To make long story short - the fix tries to build timestamp only when there is a property in rules defined.
To use it in own project you have to extend CDateValidator and CDateTimeParser.
Related
I need a hand here
The default OutSystems timezone is UTC
There's an Action called ConvertFromTimeZone(1,2,3)
1- You write the Date and Time, no problem here.
2 & 3 - You have to write the SourceTimeZone and the DestinationTimeZone, these must be written in Text data type.
My question is: How exactly am I supposed to write it?
Thanks.
you can use GetSystemTimeZones to get the list of available timezones in the servers.
This post http://www.outsystems.com/forums/discussion/16005/convertfromtimezone/#Post67485 shows the Identifier that uniquely identifiers a timezone.
Just one correction: the default timezone isn't UTC, but the timezone set in your application server.
The value you should use in the timezone code must be one of Microsoft Time Zone Index Values (column 'Name Of Time Zone')
You can find more information about timezone conversion here:
http://www.outsystems.com/forge/component-discussions/500/Time+Zone
you can use this action ConvertFromUTC(UTC_Datetime, "GMT Standard Time") it is from the Timezone extension.
The following expression returns '366' in Ruby, implying 100 AD is a leap year (which it is not):
(Date.ordinal(101) - Date.ordinal(100)).to_i
Same with DateTime.
However, Date.leap?(100) correctly returns false.
Same results for version 1.9.1. and 2.0.0.
What gives? Should I file a bug report?
Update
Also, apparenly 1582 AD is 10 days short!
(Date.ordinal(1583) - Date.ordinal(1582)).to_i
=> 355
According to Wikipedia, 100 was indeed a leap year and 1582 did indeed skip 10 days.
Apparently, prior to 1582-10-15, Ruby interprets dates as Julian calendar dates, instead of Gregorian calendar dates. More details here:
http://teleologi.blogspot.com/2013/05/ruby-times-dates-good-bad-and-so-on.html
Apparently not a bug, but definitely violates the principle of least surprise (at least in the eyes of this coder).
How confusing!
Edit
Debate about "reasonable defaults" aside, Ruby seems to quite flexible on these touchy issues of calendar-choice, compared to other languages. I've learned that the Date and DateTime constructors can receive a "reform date" constant, which determines when the transition from Julian to Gregorian calendar occurs. The default is ITALY (1582-10-15), but ENGLAND is also an option (the jump occurs at 1752-09-14).
To avoid surprises from transitioning between calendars, I should have used the Gregorian calendar for all dates:
(Date.ordinal(i+1,1,Date::GREGORIAN) - Date.ordinal(i,1,Date::GREGORIAN)).to_i
=> 365
Also, Date.leap?(100) returned "false" because it is an alias of Date.gregorian_leap?. Meanwhile, Date.julian_leap(100) returns true. To avoid surprises, probably best to use method version of leap?, which uses whichever reform date you've picked.
Date.new(100, 1, 1, Date::JULIAN).leap?
=> true
Date.new(100, 1, 1, Date::GREGORIAN).leap?
=> false
I have a column called Start Time (it's a SharePoint Default Calendar Column). I need to validate if the Start Time is less than today or not? Without using javascript? Is this possible?
I have tried this:
Created a column called Today type as Date and Time.
Default value is current date.
Then compared the Start Time and Today in validation settings like the following:
=[Start Time] < [Today]
it seems not working. help please?
Try this code instead of yours
=[Start Time]<NOW()
I use this to validate that Start Date must be less than or equal to Today:
=[Start Date]<=Today()
...and it works for me.
The ActionView::Helpers::FormOptionsHelper provides the time_zone_options_for_select to get a list of options for a select control that includes all of the timezones with their UTC offset. The problem I'm having is how to get it to display the correct offset for when daylight savings time is in effect?
For instance U.S. Mountain time is usually -7 UTC but during the summer it's effectively -6 UTC. Is there a way to have that list correctly reflect that?
TL;DR
The time zone data you are receiving is "correct" because ActiveSupport::TimeZone and TZInfo::Timezone instances do not make assumptions about the current date, and therefore applying DST to them doesn't make "sense" in the context of the responsibility of those objects.
You notice the problem because the default model for time_zone_options_for_select, ActiveSupport::TimeZone, unfortunately returns the offset string when calling #to_s, which, if the location is currently is observing DST, will be incorrect. There is no way to fix the string values generated in the options, or even remove the offset from them.
If this isn't acceptable you'll need to skip on using time_zone_options_for_select, and use options_for_select instead, and generate the options yourself.
Some investigation
time_zone_options_for_select uses ::ActiveSupport::TimeZone as the default model parameter, so passing it in manually will not change your results. In order to construct options for a select box, that method will construct an array of tuples in the format of [time_zone.to_s, time_zone.name], for the purpose of passing it to the more generic options_for_select method. time_zone, in this case, is an instance of ::ActiveSupport::TimeZone.
The important factor here is that this time zone instance object is, conceptually, completely unrelated/divorced from the idea of "the current date". The definition of a time zone (strictly speaking) has nothing to do with the current date. We can confirm this "not using DST" issue like so:
::ActiveSupport::TimeZone.all.find { |tz| tz.name == "Adelaide" }.utc_offset
=> 34200 # 9 hours and 30 minutes, in seconds
Adelaide's non-DST time zone is ACST (Australian Central Standard Time) which is GMT+9.5. Currently (as in the time of writing), Adelaide is in DST which means they are on ACDT (Australian Central Daylight Time), which is GMT+10.5.
::ActiveSupport::TimeZone.all.find { |tz| tz.name == "Adelaide" }.now.utc_offset
=> 37800 # 10 hours and 30 minutes, in seconds
The crucial difference here is essentially what I've outlined above - the ActiveSupport::TimeZone instance is just not concerned with the current date. The class itself is a convenience wrapper around a TZInfo::DataTimezone instance, which has similar opinions on the current date - none.
If you noticed, in the second code snippet above, we called #now on the time zone object before calling #utc_offset. This returns an ActiveSupport::TimeWithZone instance, which includes information about the time zone, as well as the current date - and therefore we get an offset which reflects the fact that the current date should include the DST offset.
So, the only problem here is that including the UTC offset string in the return value of #to_s on ActiveSupport::TimeZone instances is sort of misleading in this instance. It's included because it's the "base" UTC offset for that time zone.
Resources:
Rails 6.1 time_zone_options_for_select implementation
Related GitHub issue, rails/rails#7297
Related GitHub pull request, rails/rails#22243
I had similar problem but ended up using this
time_zone_select('time_zone', TZInfo::Timezone.us_zones,
:default => "America/Los_Angeles",
:model => TZInfo::Timezone
Did you find a better solution?
I have the following times stored in an XML document, which correspond to the time when the document was created and then updated:
<create-time>2010-11-04T03:13:35.212Z</create-time>
<update-time>2010-11-03T20:18:26.331-07:00</update-time>
The document was created at 8:13 pm, and then updated 5 minutes later, at 8:18 pm, but when I show the creation dates with format-dateTime(xs:dateTime(.), '[M]/[D]/[Y]'), I get 11/4/2010 and 11/3/2010, as if the document was updated one day before it was had been created, which is obviously not the case. How can I fix this?
The create-time and update-time in your XML document are correct, but they use different timezones:
create-time is in UTC (also called Zulu time, hence the Z).
update-time is in Pacific time.
This can happen if different pieces of code set this the time, or even from the same code using different libraries or functions. For instance, if you are using XPath from XForms:
Using current-dateTime() uses a timezone from the dynamic context, which is often the current timezone for the machine on which the code is running.
Using now() always returns a UTC time.
The solution in XPath is to use the adjust-dateTime-to-timezone() function. This will normalize your dateTimes so they are in the same timezones. As an example, in an XForms output, to show just the date part of create-time you would use:
<xforms:output value="format-dateTime(adjust-dateTime-to-timezone(xs:dateTime(create-time)), '[M]/[D]/[Y]')">
<xforms:label>Creation date</xforms:label>
</xforms:output>