Forum_account wrote:
In almost all cases you have access to the number. The only way you get the textual timestamp is by converting the number to text. If you have access to the number you don't need a text2time proc, you can just remember the number. The calendar was your example of a case where you have the text string and not the number.

I cannot remember a number, as I never have the number in the first place.
I want GMs to be able to specify a date and time for an in-game event to happen, and I honestly don't believe that is such a rare thing for game creators to do.
Falacy wrote:
Murrawhip wrote:
How do you get the time stamp of when it will occur?

(preferably GUI) input from the user, convert it yourself to a time-stamp? "Feb 11, 2011 @ 12:00" could easily be put together from a few simple clicks by a user. Then just wait for time2text(world.timeofday,"MMM DD, YYYY @ hh:mm") to match it and trigger the event.

That's the best solution I've heard so far, but still not so ideal.
I use an eventhandler that orders things in the order that they need to be done, so that there is only one sleep() ever happening at once.

With your solution, I would need to check potentially hundreds of different timestamps each minute for events that could be occurring weeks/months from now, instead of just adding it to the eventhandler.
On the contrary, an event handler would be the best way to handle such a system. Though having a single one for every process in the game seems somewhat ridiculous. You would probably want to "reword" the time-stamp for easier usability, at the cost of human readability. Maybe store both.
Falacy wrote:
On the contrary, an event handler would be the best way to handle such a system. Though having a single one for every process in the game seems somewhat ridiculous. You would probably want to "reword" the time-stamp for easier sorting at the cost of readability.

Isn't that... What an eventhandler is for?
Why have 500 procs sleeping when you can have one?
1. I'm still not sure how you don't have access to the numbers. If you're just prompting the user to type in a string of the format "MMM DDD, YYYY hh:mm:ss" then you wouldn't, but that's also not a user-friendly way to select a date and time.

2. You don't have to use BYOND's timestamps and time2text proc, you can implement your own datetime object.

3. You can use BYOND's timestamps and implement your own text2time proc.

Whether this is currently possible with existing libraries is only part of the issue. Because it's possible in DM this doesn't have to be built-in. It's hard to justify the feature request when there are new features that absolutely require built-in support (example: off the top of my head, this one)
I tire of having to defend my suggestion from people who exist entirely to poke holes into what other people say on BYOND.com. If you do not like my suggestion, and still have yet to suggest a viable means of resolving the problem at hand, there is no need for you to reply here.
You are not providing constructive criticism, you are providing 'solutions' that do not address the issue at hand. I am not like you - I cannot continue to spend all of my time poking holes in what you say to defend my request.
This feature request is no doubt better than at least some of the others in the pool and you're not proposing all of those are moot - are you? I do not care if there is a better feature request.

A hell of a lot of languages have support for a similar function and I see absolutely no reason why DM shouldn't.

All-in-all, I have made my request and I will leave it up to the people who matter to make the decision - not you.
Using Convert(timestamp) in MM/DD/YY hh:ss:mm will return the time in ticks since 2000.

mob/verb/GetTicksToDate()
var/timestamp = input("Please enter a timestamp as MM/DD/YY hh:mm:ss")
var/tickstodate = Convert(timestamp)-world.realtime
if(tickstodate>0)
world << "There are [tickstodate] to [timestamp]."
else
world << "[abs(tickstodate)] ticks have passed since [timestamp]."

mob/verb/GetCurrentTimestamp()
world << "[world.realtime] : [time2text(world.realtime,"MM/DD/YY hh:mm:ss")]"
world << "[Convert(time2text(world.realtime,"MM/DD/YY hh:mm:ss"))] : [time2text(Convert(time2text(world.realtime,"MM/DD/YY hh:mm:ss")),"MM/DD/YY hh:mm:ss")]"

proc/Convert(timestamp)
var
pMonth = text2num(copytext(timestamp,1,3))
pDay = text2num(copytext(timestamp,4,6))
pYear = text2num(copytext(timestamp,7,9))
pHour = text2num(copytext(timestamp,10,12))
pMin = text2num(copytext(timestamp,13,15))
pSecond = text2num(copytext(timestamp,16,18))
if(timestamp == "[pMonth>9?"":"0"][pMonth]/[pDay>9?"":"0"][pDay]/[pYear>9?"":"0"][pYear] [pHour>9?"":"0"][pHour]:[pMin>9?"":"0"][pMin]:[pSecond>9?"":"0"][pSecond]")
var/days = dayofyear(pYear,pMonth,pDay)
var/dd = round((pYear)/4)
days+= ((pYear)*365) + dd
var/ticks = days*(10*60*60*24) + ((((((6+pHour)*60)+pMin)*60)+pSecond)*10)
return ticks
else
CRASH("Timestamp Error, Cannot convert [timestamp] in \"MM/DD/YY hh:mm:ss\" format")

proc/days_in_month(month,year)
var/leepyear = 0
var/months = list(1=31,2=28,3=31,4=30,5=31,6=30,7=31,8=31,9=30,10=31,11=30,12=31)
if((month==2) && (year/4 == round(year/4)))
leepyear=1
return months[month]+leepyear

proc/dayofyear(year,month,day)
if((month>12) || (month<1))
CRASH("Day of Month input is invalid. [month]/12")
if(day>days_in_month(month,year))
CRASH("Day of Month input is invalid. [day]/[days_in_month(month,year)]")
var/doy = 0
for(var/xx = 1,xx<month,xx++)
doy += days_in_month(xx,year)
doy+=day
return doy
Murrawhip wrote:
I tire of having to defend my suggestion from people who exist entirely to poke holes into what other people say on BYOND.com. If you do not like my suggestion, and still have yet to suggest a viable means of resolving the problem at hand, there is no need for you to reply here.

Edit: Disagreeing is a good thing. It's how things get done. If everyone commented here and said "wow, this is an awesome feature request" nothing would have ever gotten done. Because people realized it's very much possible in DM, you now have the code to do it.

Making this feature request is a way of "poking holes" in DM. You're pointing out its shortcomings with the hope that improvements will result. That's what happened here about your feature request. It's not personal - you are not the feature request. It seems like people here (Schnitzelnagler (sp?)) have trouble understanding that: just because I don't like one idea you had doesn't mean that I don't like you.


But you also said this:

If you can provide me with a library that would be able to convert a text date to BYOND's time system, natively, I would gladly drop support for this feature request.

I agree that DM should have a text2time proc but initially it sounded like you were requesting this feature because you believed it to be impossible to create such a proc using DM. I have provided several suggestions (see my last comment) and Pirion has provided code. You're the one who said if a library handles it then the feature request would not be important any more.
Pirion wrote:
Using Convert(timestamp) in MM/DD/YY hh:ss:mm will return the time in ticks since 2000.

If it was completely accurate, shouldn't these return the same? Or am I doing something wrong? They are differing by ~2 hours.

world << num2text(Convert(time2text(world.realtime,"MM/DD/YY hh:mm:ss")),10)
world << num2text(world.realtime,10)
I don't see this being terribly simple to implement, since unless dates are forced into a specific format there's no reliable way to parse them.
The same way its done in time2text(), by providing the time-stamp format.
Murrawhip wrote:
Pirion wrote:
Using Convert(timestamp) in MM/DD/YY hh:ss:mm will return the time in ticks since 2000.

If it was completely accurate, shouldn't these return the same? Or am I doing something wrong? They are differing by ~2 hours.

world << num2text(Convert(time2text(world.realtime,"MM/DD/YY hh:mm:ss")),10)
world << num2text(world.realtime,10)

Due to the way time zones work, it can be off depending on what the server time zone is on.

In the line below, the 6 is 6 hours before GMT (my time zone) so it would be accurate on a server run in CST.

var/ticks = days*(10*60*60*24) + ((((((6+pHour)*60)+pMin)*60)+pSecond)*10)


To work around the server time thing, I did create a proc in the library that I am trying to put together that will detect the time zone/allow the user to input a timezone when converting.

http://www.byond.com/developer/Pirion/Text2Time
</<>
It wasn't exactly 2 hours off. It was 2 hours and ~7.8 seconds off.
Murrawhip wrote:
It wasn't exactly 2 hours off. It was 2 hours and ~7.8 seconds off.

So take a look at Pirion's code and figure out why it's off.
world.realtime:

This is the time (in 1/10 seconds) since 00:00:00 GMT, January 1, 2000 (also known as the BYOND era).

Because this is a large number, BYOND's number system isn't capable of enough precision to deliver the exact number of 1/10 second ticks. It usually rounds off to the nearest several seconds.
Yes but, doesn't your code only use world.realtime in the first place? So why would comparing the two world.realtime values yield different results when they're accessed at the same time.
I vote yes. Pirion's script might work perfectly well, but there's no reason to exclude a reciprocal function, esepcially one that would be more robust and fully integrated. (Otherwise you could say the same of ANY reciprocal function.) Plus, this is a special case due to the precision limitations of 32-bit systems. And finally, this has a practical application for my Terulia Forum Service project's search function; having this as a built-in feature would save me a little bit of effort. =)
Page: 1 2